Payment system, method and device based on large model, medium and equipment
By interacting with users through a Large Language Model (LLM), identifying shopping intentions, and integrating merchant and payment server SDKs, automatic ordering and payment can be achieved without switching clients, solving the problem of cumbersome online shopping and payment operations and improving the user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ALIPAY COM CO LTD
- Filing Date
- 2025-08-11
- Publication Date
- 2026-05-26
Smart Images

Figure CN122089302A_ABST
Abstract
Description
[0001] This application is a divisional application. The original application has the application number 202511117216.0, the application date is August 11, 2025, and the invention title is "A payment system, method, apparatus, medium and device based on a large model". Technical Field
[0002] This specification relates to the field of computer technology, and in particular to a payment system, method, apparatus, medium and device based on a large model. Background Technology
[0003] With the development of artificial intelligence (AI) technology, large language models (LLM) have been widely applied in various fields.
[0004] Through LLM, users can obtain various information and knowledge as if communicating with real people. In particular, generative LLM can also help users generate images and computer code, greatly simplifying the tedious operations required by users in their daily life and work.
[0005] Therefore, in online shopping and payment scenarios, how to simplify the user's operations during the shopping and payment process through LLM is an urgent problem to be solved. Summary of the Invention
[0006] This specification provides a payment system, method, apparatus, storage medium, and electronic device based on a large model to partially solve the problems existing in the prior art.
[0007] The embodiments in this specification adopt the following technical solutions: This specification provides a payment system based on a large model, the system comprising: an intelligent agent, a merchant system, and a payment server; wherein: The intelligent agent is used to interact with the user through a pre-set large language model. When the large language model recognizes that the user has a purchase intention for the target product sold in the merchant system based on the interaction with the user, the intelligent agent sends a first order instruction for the target product to the merchant system. After receiving the first order instruction sent by the intelligent agent, the merchant system sends a second order instruction to the payment server based on the amount to be paid for the target product. Upon receiving the second order placement instruction, the payment server generates a payment order and returns the order identifier of the payment order to the smart agent through the merchant system. Upon receiving the order identifier, the intelligent agent sends the user's user authorization identifier to the payment server. The payment server processes the payment order based on the received user authorization identifier.
[0008] This specification provides a payment method based on a large model, the method comprising: The intelligent agent interacts with the user through a pre-set large language model. When the large language model identifies that the user has the intention to purchase the target product sold in the merchant system, it sends a first order instruction for the target product to the merchant system, so that the merchant system sends a second order instruction to the payment server according to the amount to be paid for the target product. Receive the order identifier of the payment order generated by the payment server according to the second order placement instruction; Send the user's authorization identifier to the payment server, so that the payment server can make payment for the payment order based on the user authorization identifier.
[0009] This specification provides a payment method based on a large model, the method comprising: The merchant system receives a first order instruction for a target product from an intelligent agent. The first order instruction is sent by the intelligent agent when it interacts with the user through a pre-set large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. Based on the amount to be paid for the target product, a second order placement instruction is sent to the payment server. Receive the order identifier of the payment order returned by the payment server after generating the payment order according to the second order instruction; The order identifier is returned to the agent, which then sends the user's authorization identifier to the payment server based on the order identifier, so that the payment server can make payment for the order according to the user authorization identifier.
[0010] This specification provides a payment method based on a large model, the method comprising: The payment server receives a second order instruction from the merchant system; the second order instruction is sent by the merchant system after receiving the first order instruction for the target product, based on the amount to be paid for the target product; the first order instruction is sent to the merchant system by the intelligent agent when it interacts with the user through a pre-set large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. In response to the second order placement instruction, a payment order is generated that includes the merchant's payment account and the amount to be paid; The order identifier of the payment order is returned to the intelligent agent through the merchant system; Receive the user authorization identifier of the user returned by the intelligent agent in response to the triggering of the order identifier; The payment order is processed based on the received user authorization identifier.
[0011] This specification provides a payment device based on a large model, the device comprising: The interaction module is used to interact with the user through a pre-set large language model. When the large language model identifies that the user has the intention to purchase the target product sold in the merchant system, it sends a first order instruction for the target product to the merchant system, so that the merchant system sends a second order instruction to the payment server according to the amount to be paid for the target product. The receiving module is used to receive the order identifier of the payment order generated by the payment server according to the second order placement instruction; The sending module is used to send the user's user authorization identifier to the payment server, so that the payment server can make payment for the payment order based on the user authorization identifier.
[0012] This specification provides a payment device based on a large model, the device comprising: The receiving module is used to receive the first order instruction for the target product sent by the intelligent agent. The first order instruction is sent by the intelligent agent when it interacts with the user through a preset large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. The order placement module is used to send a second order placement instruction to the payment server based on the amount to be paid for the target product. The receiving module is further configured to receive the order identifier of the payment order returned by the payment server after generating the payment order according to the second order instruction; The sending module is used to return the order identifier to the intelligent agent, so that the intelligent agent can send the user's user authorization identifier to the payment server based on the order identifier, so that the payment server can make payment for the payment order according to the user authorization identifier.
[0013] This specification provides a payment device based on a large model, the device comprising: The receiving module is used to receive a second order instruction sent by the merchant system. The second order instruction is sent by the merchant system after receiving the first order instruction for the target product, based on the amount to be paid for the target product. The first order instruction is sent to the merchant system by the intelligent agent when it interacts with the user through a preset large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. The generation module is used to generate a payment order containing the merchant's payment account and the amount to be paid in response to the second order placement instruction; The sending module is used to return the order identifier of the payment order to the smart agent through the merchant system; The receiving module is further configured to receive the user authorization identifier of the user returned by the intelligent agent in response to the triggering of the order identifier; The payment module is used to process the payment order based on the received user authorization identifier.
[0014] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned payment method based on a large model.
[0015] This specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the aforementioned payment method based on a large model.
[0016] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: This specification discloses a payment system based on a large model (LLM). When an agent interacts with a user through a pre-built LLM, if it detects that the user intends to purchase a target product in the merchant's system, it sends a first order instruction for that target product to the merchant's system. The merchant's system then sends a second order instruction to the payment server based on the amount due for the target product, causing the payment server to generate a payment order and return the order identifier to the agent. In response to the order identifier, the agent sends the user's authorization identifier to the payment server, enabling the payment server to process the payment order based on the authorization identifier. Through this payment system, users can directly place orders and make payments through the agent via chat with the LLM, without frequently switching between and launching the e-commerce client for the merchant's system and the payment client for the payment server, greatly simplifying the online shopping and payment process. Attached Figure Description
[0017] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1 A schematic diagram of a payment system structure based on a large model is provided for embodiments of this specification; Figure 2 A flowchart illustrating the payment method provided in the embodiments of this specification; Figure 3 This is a schematic diagram illustrating the interface through which the intelligent agent provided in the embodiments of this specification interacts with the user via LLM, displaying the target product. Figure 4 This is a schematic diagram showing the payment account and the amount to be paid in a floating window on the interface where the intelligent agent interacts with the user through the LLM, as provided in the embodiments of this specification. Figure 5 A schematic diagram illustrating the signing process between the intelligent agent and the payment server when the agent is located on a mobile terminal, as provided in the embodiments of this specification. Figure 6 A schematic diagram illustrating the signing process between the smart agent located on the vehicle's infotainment system and the payment server, as provided in the embodiments of this specification. Figure 7 A schematic diagram of a first type of payment device based on a large model, provided for embodiments of this specification; Figure 8 A schematic diagram of a second type of payment device based on a large model, provided for embodiments of this specification; Figure 9 A schematic diagram of a third type of payment device based on a large model provided in the embodiments of this specification. Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this specification. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.
[0019] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.
[0020] Figure 1 This is a schematic diagram of a payment system architecture based on a large model, provided as an embodiment of this specification. The payment system specifically includes: an agent, a merchant system, and a payment server. Wherein: The intelligent agent comes pre-installed with an LLM (Limited Language Management System), which is used to interact with users through at least one of the following methods: voice, text, or vision. The intelligent agent can also integrate a payment server-side software development kit (SDK), which contains the corresponding APIs for the payment server, allowing the intelligent agent to interact with the payment server. Furthermore, the intelligent agent can integrate an e-commerce SDK for the merchant system, which contains the corresponding application programming interface (API), allowing the intelligent agent to interact with the merchant system through these APIs.
[0021] A merchant system is used to provide users with online shopping functionality, such as an e-commerce platform, a food delivery platform, or an online ordering platform for a branded coffee shop or fast food restaurant. In traditional online shopping scenarios, a merchant system displays information about the various products it sells. Users can select their desired products and place an order through the merchant system. The merchant system can also activate a payment client, which, along with its corresponding payment server, processes the payment for the user's purchase.
[0022] The payment server, located in the background, is used to collect the triples required for payment, namely the payment account, the receiving account, and the amount to be paid. It generates a payment order based on the triples required for payment and completes the payment for the order according to the triples.
[0023] To enable users to directly order desired products from the merchant system through the intelligent agent during their LLM interaction with the intelligent agent, and also directly pay for the products through the intelligent agent, without having to switch back and forth between the intelligent agent, the e-commerce client corresponding to the merchant system, and the payment client corresponding to the payment server, thus simplifying the user's operation in the shopping and payment process, based on the above... Figure 1 The system shown in this specification provides embodiments as follows: Figure 2 The payment methods shown.
[0024] Figure 2 The payment method flowchart provided for the embodiments of this specification specifically includes the following steps: S200: The agent interacts with the user through a pre-configured LLM.
[0025] In one embodiment provided in this specification, the intelligent agent may include an intelligent agent client located at the front end and an intelligent agent server located at the back end. The LLM can be pre-deployed on the intelligent agent server at the back end. Users can input one or more forms of interactive information such as text, voice, and vision through the intelligent agent client at the front end. The intelligent agent client then sends the interactive information input by the user to the LLM deployed in the intelligent agent server at the back end. The LLM can analyze the interactive information input by the user based on its own reasoning ability and / or a preset knowledge base, and output corresponding response information back to the intelligent agent client at the front end. The intelligent agent client then displays the response information to the user to complete the interaction between the user and the LLM.
[0026] In another embodiment provided in this specification, the agent may also include only the agent client at the front end. The LLM is directly deployed in the agent client at the front end. In this case, the agent client provides both the function of directly receiving interactive information input by the user and the function of the agent server in the above embodiment at the front end.
[0027] Regardless of the deployment method of the LLM, users need to log in to their agent account in the agent in order to interact with the LLM pre-deployed in the agent in the above manner.
[0028] S202: When the LLM recognizes that the user has the intention to purchase the target product sold in the merchant system based on the interaction with the user, it sends the first order instruction for the target product to the merchant system.
[0029] In the embodiments of this specification, the intelligent agent may have a merchant system's e-commerce SDK pre-integrated in it. When the LLM deployed in the intelligent agent recognizes that the user has a purchase intention for the target product sold in the merchant system during the interaction with the user, the intelligent agent can call the merchant system's e-commerce SDK and send a first order instruction for the target product to the merchant system through the API of the merchant system contained in the e-commerce SDK.
[0030] The intelligent agent can call the e-commerce SDK of the merchant system to obtain all or part of the target product information from the merchant system and display it in the interface where the intelligent agent interacts with the user via LLM, providing an order button. When the user clicks the order button on the interface, the agent sends the first order instruction for the target product to the merchant system, such as... Figure 3 As shown.
[0031] When an intelligent agent recognizes that a user has the intention to purchase goods sold in a merchant system, but cannot yet determine the target product the user wants to buy, it can also obtain all or part of the goods sold in the merchant system through the e-commerce SDK of the merchant system and display them in the interface through which the intelligent agent interacts with the user via LLM. An order button is provided for each displayed product. When the user clicks the order button corresponding to a product in the interface, that product can be taken as the target product, and a first order instruction for the target product can be sent to the merchant system.
[0032] Specifically, the intelligent agent can first use LLM to identify the semantics of the user's interaction with the large language model, and based on this semantics, identify the type of goods the user needs. This is because in general chat conversations, users mostly only say what type of goods they need, without deliberately emphasizing that they need goods from a specific merchant. For example, users will mostly say to LLM "I want to drink a cup of coffee," and may not deliberately emphasize "I want to drink coffee from a certain brand." Therefore, LLM can first identify the type of goods the user needs.
[0033] After identifying the product type, since the agent may have integrated e-commerce SDKs from more than one merchant system, the LLM can determine the merchant system corresponding to the e-commerce SDK that matches the identified product type, based on the natural language descriptions of each integrated e-commerce SDK. This target merchant system is then identified. The description of each e-commerce SDK must include at least a description of the product type sold by the corresponding merchant system in natural language. The LLM can then use this description to determine the target merchant system that matches the product type required by the user.
[0034] If there are multiple merchant systems that match the type of goods the user needs, the LLM can either use all of these merchant systems as target merchant systems, or it can continue to interact with the user and ask the user about their preferences for these matching merchant systems, allowing the user to choose the target merchant system from among these matching merchant systems. For example, the LLM can reply to the user, "I can order coffee from brand A, brand B, and brand C for you. Which brand do you prefer?"
[0035] Once the target merchant system is identified, the intelligent agent can obtain product information for all products of that type sold by the target merchant system based on the API of the target merchant system contained in the e-commerce SDK corresponding to the target merchant system. The obtained product information is then displayed on the interface where the LLM interacts with the user. The product corresponding to the product information selected by the user on the interface is then identified as the target product for which the user has the intention to purchase. Similarly, the agent sends a first order instruction for the target product to the target merchant system through the API of the target merchant system to place an order for the target product on the target merchant system.
[0036] In summary, when the intelligent agent identifies a user's purchase intent through LLM, it does not require the user to launch the merchant's corresponding e-commerce client to place an order for the target product, nor does it need to obtain information about the products sold by the merchant's system through the e-commerce client. Instead, it completely bypasses the e-commerce client. Figure 3 As shown, orders can be placed directly with the merchant system through the e-commerce SDK of the merchant system integrated into the agent, allowing the agent to interact with the user via LLM.
[0037] Furthermore, when the LLM identifies a user's purchase intention for a target product, it can specifically identify the purchase time corresponding to that intention. Upon the arrival of that purchase time, the LLM then sends a first order instruction for the target product to the merchant system via the aforementioned merchant system's SDK. The user's purchase intention can include immediate purchase intention, delayed purchase intention, and periodic purchase intention. The purchase time for an immediate purchase intention is the moment the LLM identifies that intention; the purchase time for a delayed purchase intention is a certain period after the LLM identifies that intention; and the purchase time for a periodic purchase intention is multiple points in time after each identical period following the LLM's identification of that intention.
[0038] For example, when a user inputs the interaction message "I want to drink a certain brand of coffee, do you have any recommendations?", the LLM can identify the user's purchase intention as an immediate purchase intention, meaning the user wants to drink coffee now; when the user inputs the interaction message "Order me a certain brand of coffee during my lunch break", the LLM can identify the user's purchase intention as a delayed purchase intention, with the purchase time being lunch break; when the user inputs the interaction message "Order me a certain brand of coffee every day at 12 noon", the LLM can identify the user's purchase intention as a recurring purchase intention.
[0039] S204: After receiving the first order instruction from the smart agent, the merchant system sends a second order instruction to the payment server based on the amount to be paid for the target product.
[0040] After receiving the first order instruction from the intelligent agent, the merchant system can first determine its own payment account and the outstanding payment amount for the target product corresponding to the first order instruction. Then, based on the product information, a business order is generated. This business order exists only within the merchant system and is used to record the sales status of its products. Simultaneously, the merchant system can also generate a pre-order instruction based on its own payment account and the outstanding payment amount for the target product, which is then sent to the payment server as a second order instruction.
[0041] The reason why the second order instruction generated by the merchant system is called a pre-order instruction in this manual is that the triple required to complete the payment includes the receiving account, the payment account, and the amount to be paid. However, the second order instruction sent by the merchant system to the payment server at this time only contains the receiving account and the amount to be paid. The payment account is unknown at this time, and the triple is not complete. At this time, the payment server cannot directly complete the payment based on the second order instruction, but it can generate a payment order for subsequent payment based on the collected receiving account and the amount to be paid. It can also determine a unique order identifier to identify the payment order. Therefore, the order instruction generated by the merchant system is called a pre-order instruction.
[0042] It should be noted that, since the merchant system has already sent the pre-order instruction to the payment server located in the background for completing the payment in this embodiment of the specification, the payment process has been initiated by the merchant system at this time.
[0043] S206: In response to the received second order instruction, the payment server generates a payment order and sends the order identifier of the payment order to the merchant system.
[0044] S208: The merchant system returns the order identifier to the smart agent.
[0045] After receiving the pre-order instruction (i.e. the second order instruction) sent by the merchant system, the payment server can generate a payment order containing the merchant's payment account and the amount to be paid for the target product, based on the payment account and amount to be paid for the target product contained in the pre-order instruction, and determine the order identifier of the payment order.
[0046] This payment order is used to complete the payment, but since the payment account in the triple required to complete the payment is still unknown at this time, the payment cannot be completed based on this payment order. Only the payment order can be generated and the order identifier of the payment order can be determined.
[0047] After generating a payment order and determining a unique order identifier for it, the payment server can return this order identifier to the merchant system. The merchant system then returns the order identifier to the smart agent.
[0048] S210: In response to the received order identifier, the intelligent agent sends the user's authorization identifier to the payment server.
[0049] In the embodiments described in this specification, the intelligent agent also integrates a payment SDK corresponding to the payment server. After receiving the order identifier returned by the merchant system, the intelligent agent will trigger the intelligent agent to call the payment SDK and send the user's authorization identifier to the payment server through the API corresponding to the payment server contained in the SDK.
[0050] Specifically, in the embodiments of this specification, the user's user authorization identifier is pre-bound to the smart agent account used by the user to log in to the smart agent. After the smart agent responds to the order identifier to trigger the call to the payment SDK, it can use the payment SDK to determine the currently logged-in smart agent account, query the user authorization identifier pre-bound to the smart agent account, and send the queried user authorization identifier to the payment server through the API corresponding to the payment server.
[0051] Among them, the smart agent and the payment server can sign an agreement in advance. Through the agreement, the user's smart agent account is bound to the user's user authorization identifier. The specific signing and binding process will be described in detail below.
[0052] S212: The payment server processes the payment order based on the received user authorization identifier.
[0053] After receiving the user authorization identifier sent by the smart agent, the payment server can query the payment account bound to the user authorization identifier and simultaneously return a response message to the smart agent. Upon receiving the response message, the smart agent can collect the user's identity information and send the collected identity information to the payment server through the payment SDK. The payment server then verifies the user's identity based on the queried payment account and the received identity information, and if the verification is successful, it processes the payment order according to the payment account.
[0054] In step S206, since the pre-order instruction sent by the merchant system to the payment server only contains the receiving account and the amount to be paid, although the merchant system has initiated the payment process, the payment order generated by the payment server lacks a payment account because the required three-tuple for payment is not complete. Therefore, the payment server cannot directly complete the payment based on the pre-order instruction. However, in step S212, the payment server can query the payment account bound to the user authorization identifier sent by the smart agent. The payment server can add the queried payment account to the payment order. At this point, the three-tuple in the payment order is complete, and the payment server can complete the payment based on the payment order.
[0055] Furthermore, to ensure payment security, after the payment server finds the payment account, it may not process the payment order. Instead, it may return a response message to the agent, which will then collect the user's identity information based on the response message and return it to the payment server via the payment SDK. The payment server will then verify the user's identity based on the received identity information. If the verification is successful, the payment will be completed according to the payment order. If the verification fails, the payment order will be refused.
[0056] In the embodiments of this specification, when the intelligent agent sends a user authorization identifier to the payment server via the payment SDK to enable the payment server to complete the payment, the user still does not need to switch to and launch the payment client corresponding to the payment server. The aforementioned identity information collection and payment can still be completed through the interface between the intelligent agent and the LLM. Specifically, after the payment server finds the payment account, it can return the found payment account and the amount to be paid in the response information to the intelligent agent. The intelligent agent can then display the payment account and the amount to be paid in a floating window on the interface between the user and the LLM, and prompt the user to collect identity information, such as... Figure 4 As shown.
[0057] exist Figure 4 In the process, after the user clicks the "Confirm Payment" button, the AI agent can prompt the user to enter the password corresponding to the payment account, collect facial recognition, fingerprint recognition, voiceprint recognition, or other methods to collect their identity information. After collecting the identity information, the AI agent sends it to the payment server via the SDK. The payment server then verifies the user's identity using pre-stored standard identity information corresponding to the payment account and the identity information collected by the AI agent.
[0058] Using the above method, users can directly place orders and make payments through the AI agent by chatting with the LLM, without having to frequently switch and launch the e-commerce client corresponding to the merchant system and the payment client corresponding to the payment server, which greatly simplifies the operations required for users to shop and pay online.
[0059] In the embodiments described in this specification, the intelligent agent can be located on a mobile terminal such as a mobile phone or tablet computer. Specifically, it can be installed directly on the mobile terminal in the form of an intelligent agent client, or it can be attached to other host programs in the form of a mini-program. In addition, the intelligent agent can also be located on in-vehicle systems and various smart wearable devices, such as smartwatches and glasses. The following describes the process of the intelligent agent signing an agreement with the payment server to bind the intelligent agent account and the payment account, taking the intelligent agent located on a mobile terminal and the in-vehicle system as examples respectively.
[0060] Figure 5The schematic diagram of the signing process between the intelligent agent located on a mobile terminal and the payment server, as provided in the embodiments of this specification, specifically includes the following steps: S500: The agent generates contract parameters based on the user's agent account.
[0061] In the embodiments described in this specification, the intelligent agent can generate contract parameters that at least include the user's intelligent agent account in response to a user's request to make a payment through the payment server. In addition to the user's intelligent agent account, the contract parameters may also include other information, such as intelligent agent version information and contract validity period information.
[0062] S502: Call the payment SDK integrated in the smart agent, start the payment client installed on the mobile terminal corresponding to the payment server through the payment SDK, and transmit the signing parameters to the payment client.
[0063] When an agent is installed directly on a mobile terminal as an agent client, or attached to other host programs installed on the mobile terminal as a mini-program, the agent can call the payment SDK corresponding to the payment server, and through the payment SDK, launch the payment client corresponding to the payment server also installed on the mobile terminal, and transmit the contract parameters to the payment client.
[0064] This is because although the payment SDK includes the payment server's API, allowing the agent to communicate directly with the payment server, the payment SDK cannot currently determine the payment account of the user to be bound. The payment account logged into the payment client is the payment account that the user needs to bind. Therefore, the agent needs to invoke the payment client through the payment SDK and send the signing parameters to the payment server through the payment client that is already logged into the payment account.
[0065] At this point, the payment system based on the large model in this specification also includes Figure 1 The payment client is not shown in the image.
[0066] S504: The payment client sends the contract parameters to the payment server.
[0067] S506: The payment server generates a user authorization identifier for querying the payment account based on the payment account currently logged in by the payment client.
[0068] After a payment client that has logged into a payment account sends the contract parameters to the payment server, the payment server can determine the payment account that the payment client is currently logged into and generate a user authorization identifier for querying that payment account.
[0069] It should be noted that the user authorization identifier mentioned in this specification is not the payment account. This is for security reasons. The payment account is not exposed to the smart agent in plaintext. Instead, the payment server generates a string that allows the user to query the payment account, which serves as the user authorization identifier. In other words, what is directly bound to the smart agent's account is not the user's payment account, but the user authorization identifier that allows the user to query the payment account. Specifically, the payment server can generate a token, generate the user authorization identifier based on the token, and then bind the user authorization identifier to the payment account.
[0070] S508: The payment server binds the generated user authorization identifier with the smart agent account in the received contract parameters, and generates contract information based on the binding relationship between the user authorization identifier and the smart agent account.
[0071] After the payment server generates a user authorization identifier, it can bind this identifier to the smart agent account in the received contract parameters and generate contract information based on the binding relationship between the two. At this time, the contract information includes the aforementioned bound user authorization identifier and smart agent account, and may also include other information such as smart agent version information and contract validity period information.
[0072] S510: Return the signed information to the payment client.
[0073] S512: The payment client returns the contract information to the payment SDK. The smart agent receives the contract information through the payment SDK and stores it.
[0074] After the payment server generates the contract information, it can return the contract information to the smart agent through the payment client and the payment SDK in the smart agent, and the smart agent will store the contract information.
[0075] Correspondingly, in Figure 2 In step S210, when the smart agent sends the user authorization identifier to the payment server, it can first determine the currently logged-in smart agent account, query the stored contract information associated with the smart agent account, then determine the user authorization identifier bound to the smart agent account in the contract information, and finally send the user authorization identifier to the payment server.
[0076] In step S212, after receiving the user authorization identifier sent by the intelligent agent, the payment client first queries the payment account bound to that user authorization identifier and determines the pre-set verification method for that payment account, such as password, facial recognition, fingerprint, or voiceprint. The client then returns the queried payment account, the amount to be paid, and the verification method in a response message to the intelligent agent. The intelligent agent then displays the payment account and the amount to be paid through the user's interface with the LLM, and collects the user's identity information corresponding to the verification method carried in the response message. This collected identity information is then returned to the payment server via the payment SDK. The payment server then verifies the user's identity based on the pre-saved standard identity information corresponding to the payment account under that verification method, and the user's identity information collected by the intelligent agent.
[0077] When the contract information includes agent version information and contract validity period information, after collecting the user's identity information, the agent must return the user's identity information, as well as the agent's current version information and the current timestamp, to the payment server. The payment server, in addition to verifying the user's identity based on the user's identity information, also needs to determine the agent's legitimacy based on the agent's current version information and the agent version information contained in the contract information, and determine whether the contract information is still valid based on the current timestamp and the contract validity period information contained in the contract information. If the user's identity verification is successful, and the agent is confirmed to be legitimate and the contract information is still valid, then the payment order generated in step S206 is processed according to the payment account; otherwise, the payment order is rejected.
[0078] Figure 6 The schematic diagram of the signing process between the smart agent located on the vehicle's infotainment system and the payment server, as provided in the embodiments of this specification, specifically includes the following steps: S600: The agent generates contract parameters based on the user's agent account.
[0079] Similar to step S500, the agent can respond to a user's request to make a payment through the payment server by generating contract parameters that include at least the user's agent account. In addition to the user's agent account, the contract parameters may also include other information such as agent version information and contract validity period information.
[0080] S602: Invoke the payment SDK integrated in the smart agent, and through the payment SDK and the vehicle system, provide the signing parameters to the mobile terminal that has the payment client corresponding to the payment server installed.
[0081] When the intelligent agent is located on the vehicle's infotainment system, the intelligent agent can call the payment SDK corresponding to the payment server, and through the payment SDK and the vehicle's infotainment system, provide the aforementioned contract parameters to the payment client installed on the mobile terminal.
[0082] Specifically, the payment SDK can use a wireless communication channel (such as Bluetooth) or a wired communication channel (such as Type-C) between the vehicle's infotainment system and the mobile terminal to transmit the contract parameters to the payment client installed on the mobile terminal. Alternatively, the payment SDK can encode the aforementioned contract parameters into a graphic code (including a QR code) and prompt the user to scan the graphic code using the payment client installed on the mobile terminal to obtain the contract parameters.
[0083] At this point, the payment system based on the large model in this specification also includes Figure 1 The mobile terminal with the payment client installed is not shown in the image.
[0084] S604: The mobile terminal sends the contract parameters to the payment server through the payment client.
[0085] S606: The payment server generates a user authorization identifier for querying the payment account based on the payment account currently logged in by the payment client.
[0086] Similar to steps S504-S506, after the payment client, which has logged into its payment account, sends the contract parameters to the payment server, the payment server can determine the payment account currently logged into by the payment client and generate a user authorization identifier for querying that payment account. This user authorization identifier does not refer to the payment account itself, and will not be elaborated further here.
[0087] S608: The payment server binds the generated user authorization identifier to the smart agent account in the received contract parameters, and generates contract information based on the binding relationship between the user authorization identifier and the smart agent account.
[0088] After the payment server generates a user authorization identifier, it can bind this identifier to the smart agent account in the received contract parameters and generate contract information based on the binding relationship between the two. At this time, the contract information includes the aforementioned bound user authorization identifier and smart agent account, and may also include other information such as smart agent version information and contract validity period information.
[0089] S610: Return the signed information to the mobile terminal.
[0090] S612: The mobile terminal returns the contract information to the payment SDK through the vehicle system. The smart agent receives the contract information through the payment SDK and stores it.
[0091] After the payment server generates the contract information, it can return the contract information to the smart agent through the payment client installed on the mobile terminal, the vehicle system, and the payment SDK in the smart agent. The smart agent then stores the contract information.
[0092] Correspondingly, in Figure 2 In step S210, when the smart agent sends the user authorization identifier to the payment server, it can first determine the currently logged-in smart agent account, query the stored contract information associated with the smart agent account, then determine the user authorization identifier bound to the smart agent account in the contract information, and finally send the user authorization identifier to the payment server.
[0093] In step S212, since the intelligent agent is located on the vehicle's infotainment system, it indicates that the user is likely driving. Entering a password, fingerprint, or facial recognition for authentication at this time could pose a risk to the user. Therefore, in this embodiment, when the intelligent agent is on the vehicle's infotainment system, after receiving the user authorization identifier sent by the intelligent agent, the payment client first queries the payment account bound to that authorization identifier. The queried payment account and the amount to be paid are then sent back to the intelligent agent in a response message. The intelligent agent then displays the payment account and the amount to be paid through the user's interface with the LLM (Local Management System), and collects the user's voiceprint information as their identity information. This voiceprint information is then returned to the payment server via the payment SDK. The payment server then authenticates the user based on the pre-saved standard voiceprint information corresponding to the payment account and the voiceprint information collected by the intelligent agent.
[0094] When the contract information includes agent version information and contract validity period information, after collecting the user's voiceprint information, the agent must return the user's voiceprint information, as well as the agent's current version information and the current timestamp, to the payment server. The payment server, in addition to verifying the user's identity based on the voiceprint information, also needs to determine the agent's legitimacy based on the agent's current version information and the agent version information contained in the contract information, and determine whether the contract information is still valid based on the current timestamp and the contract validity period information contained in the contract information. If the user's identity verification is successful, and the agent is confirmed to be legitimate and the contract information is still valid, then the payment order generated in step S206 is processed according to the payment account; otherwise, the payment order is rejected.
[0095] Furthermore, regardless of whether the smart agent is located on a mobile terminal or in the vehicle's infotainment system, before the payment server binds the user authorization identifier it generates to the smart agent account in the received contract parameters, it can send an authentication request to the smart agent through the payment client and the payment SDK integrated in the smart agent. This allows the smart agent to collect the user's identity information and return it to the payment server through the payment SDK and payment client. The payment server then uses this identity information and the payment account currently logged into the payment client to authenticate the user. If the authentication is successful, the user authorization identifier and smart agent account are bound, and contract information is generated. Otherwise, the binding and contract signing are refused.
[0096] When the smart agent is located on the vehicle's infotainment system, after the payment server verifies the user's identity, it can collect the user's voiceprint information again through the payment client, the payment SDK integrated in the smart agent, and the vehicle's infotainment system. This voiceprint information is stored as the user's standard voiceprint information so that when the user pays through the smart agent, the stored standard voiceprint information can be used to verify the user's identity.
[0097] Whether it is Figure 5 The signing process shown is still as follows Figure 6 The signing process shown illustrates this when the agent includes an agent client at the front end and an agent server at the back end. Figure 5 The intelligent agent installed on the mobile terminal is the intelligent agent client. Figure 6 The intelligent agent installed on the vehicle's infotainment system is also the intelligent agent client, while the intelligent agent server is located in the backend. Figure 5 and Figure 6 The details are not shown in the provided text. In steps S500 and S600, the intelligent agent client, responding to the user's request to make payment through the payment server, sends a request to the intelligent agent server to generate contract parameters. The intelligent agent server then generates the aforementioned contract parameters and returns them to the intelligent agent client. The intelligent agent client then continues to execute subsequent steps S502 and S602, as well as subsequent steps. Furthermore, in steps S510 and S610, after the payment server returns the contract information to the payment client or mobile terminal, it can also asynchronously send the contract information directly to the intelligent agent server for storage.
[0098] The above describes a payment system and method based on a large model, as provided in the embodiments of this specification. Based on the same idea, this specification also provides corresponding devices, storage media, and electronic devices.
[0099] Figure 7 This is a schematic diagram of a first type of payment device based on a large model, provided in the embodiments of this specification. This first payment device can be applied to intelligent agents, and the device includes: The interaction module 701 is used to interact with the user through a pre-set large language model, and when the large language model identifies that the user has the intention to purchase the target product sold in the merchant system, it sends a first order instruction for the target product to the merchant system, so that the merchant system sends a second order instruction to the payment server according to the amount to be paid for the target product. The receiving module 702 is used to receive the order identifier of the payment order generated by the payment server according to the second order placement instruction; The sending module 703 is used to send the user's user authorization identifier to the payment server, so that the payment server can make payment for the payment order based on the user authorization identifier.
[0100] Optionally, the intelligent agent integrates at least one e-commerce SDK corresponding to a merchant system; The interaction module 701 is specifically used to: identify the semantics of the user's interaction with the large language model through the large language model; identify the product type of the product required by the user based on the semantics; determine the merchant system corresponding to the e-commerce SDK that matches the identified product type based on the description information of each e-commerce SDK, and designate it as the target merchant system; obtain the product information of the product type sold by the target merchant system based on the API of the target merchant system contained in the e-commerce SDK corresponding to the target merchant system, and display the obtained product information on the interface where the large language model interacts with the user; and determine the product corresponding to the product information selected by the user on the interface as the target product for which the user has the intention to purchase.
[0101] Optionally, the device integrates a payment SDK corresponding to the payment server; The sending module 703 is specifically used to, in response to the received order identifier, call the payment SDK; and send the user's user authorization identifier to the payment server through the API corresponding to the payment server included in the SDK.
[0102] Optionally, the device is located on a mobile terminal, and / or the intelligent agent is located on the vehicle's infotainment system.
[0103] Optionally, when the device is located on a mobile terminal, the device further includes: The signing module 704 is used to generate signing parameters based on the user's smart agent account; call the payment SDK corresponding to the payment server integrated in the device, and launch the payment client on the mobile terminal corresponding to the payment server through the payment SDK, and transmit the signing parameters to the payment client, so that the payment client sends the signing parameters to the payment server, so that the payment server generates a user authorization identifier for querying the payment account based on the payment account currently logged in by the payment client, binds the generated user authorization identifier with the smart agent account in the received signing parameters, generates signing information based on the binding relationship between the user authorization identifier and the smart agent account, and returns the signing information to the device through the payment client and the payment SDK; receive the signing information and store it.
[0104] Optionally, when the device is located on the vehicle infotainment system, the device further includes: The signing module 704 is used to generate signing parameters based on the user's smart agent account; call the payment SDK corresponding to the payment server integrated in the device, and provide the signing parameters to a mobile terminal with the payment client corresponding to the payment server installed through the payment SDK and the vehicle system, so that the mobile terminal sends the signing parameters to the payment server through the payment client, so that the payment server generates a user authorization identifier for querying the payment account based on the payment account currently logged in by the payment client, binds the generated user authorization identifier with the smart agent account in the received signing parameters, generates signing information based on the binding relationship between the user authorization identifier and the smart agent account, and returns the signing information to the device through the payment SDK and the vehicle system; receive the signing information and store it.
[0105] Optionally, the sending module 703 is specifically used to: determine the currently logged-in smart agent account; query the stored contract information associated with the smart agent account; determine the user authorization identifier bound to the smart agent account in the contract information; and send the user authorization identifier to the payment server.
[0106] Optionally, the sending module 703 is further configured to: receive, via the payment SDK, a response message returned by the payment server after querying the payment account corresponding to the user authorization identifier based on the user authorization identifier; in response to the response message, collect the user's identity information; send the identity information to the payment server, so that the payment server can verify the user's identity based on the payment account and the received identity information, and, upon successful verification, make payment for the payment order based on the payment account.
[0107] Optionally, the sending module 703 is specifically used to collect the user's voiceprint information through the vehicle system when the smart agent is located on the vehicle system, as the user's identity information.
[0108] Figure 8 This is a schematic diagram of a second type of payment device based on a large model, provided in the embodiments of this specification. This second type of payment device can be applied to a merchant system, and the device includes: The receiving module 801 is used to receive a first order instruction for a target product sent by the intelligent agent. The first order instruction is sent by the intelligent agent when it interacts with the user through a preset large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. The order placement module 802 is used to send a second order placement instruction to the payment server based on the amount to be paid for the target product. The receiving module 801 is further configured to receive the order identifier of the payment order returned by the payment server after generating the payment order according to the second order instruction; The sending module 803 is used to return the order identifier to the intelligent agent, so that the intelligent agent sends the user's user authorization identifier to the payment server based on the order identifier, so that the payment server pays the payment order according to the user authorization identifier.
[0109] Optionally, the order placement module 802 is specifically used to: determine the merchant system's own payment account and the amount to be paid corresponding to the target product; generate a pre-order instruction based on the payment account and the amount to be paid, as a second order instruction; and send the second order instruction to the payment server.
[0110] Figure 9 This is a schematic diagram of a third type of payment device based on a large model, provided in the embodiments of this specification. This third type of payment device can be applied to a payment server. The device includes: The receiving module 901 is used to receive a second order instruction sent by the merchant system; the second order instruction is sent by the merchant system after receiving the first order instruction for the target product, based on the amount to be paid for the target product; the first order instruction is sent to the merchant system by the intelligent agent when it interacts with the user through a preset large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. The generation module 902 is used to generate a payment order containing the merchant's payment account and the amount to be paid in response to the second order placement instruction; The sending module 903 is used to return the order identifier of the payment order to the smart agent through the merchant system; The receiving module 901 is further configured to receive the user authorization identifier of the user returned by the intelligent agent in response to the triggering of the order identifier; The payment module 904 is used to make payment for the payment order based on the received user authorization identifier.
[0111] Optionally, the device further includes: The signing module 905 is used to receive signing parameters sent by the intelligent agent through a payment client corresponding to the payment server, the signing parameters including the intelligent agent account logged in by the intelligent agent; generate a user authorization identifier for querying the payment account based on the payment account currently logged in by the payment client; bind the user authorization identifier to the intelligent agent account included in the signing parameters; generate signing information based on the binding relationship between the user authorization identifier and the intelligent agent account; and return the signing information to the intelligent agent for storage through the payment client.
[0112] Optionally, the payment module 904 is specifically configured to: query the payment account bound to the received user authorization identifier; return a response message to the intelligent agent; receive the user's identity information collected and sent by the intelligent agent in response to the response message; verify the user's identity based on the payment account and the received identity information; and, upon successful verification, process the payment order based on the payment account.
[0113] Optionally, when the intelligent agent is located on the vehicle's infotainment system, the identity information includes the user's voiceprint information; The payment module 904 is specifically used to determine the standard voiceprint information corresponding to the pre-saved payment account; and to verify the user's identity based on the determined standard voiceprint information and the user's voiceprint information collected and sent by the intelligent agent.
[0114] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can be used to perform the large-model-based payment method described above.
[0115] based on Figure 2 , Figure 5 and Figure 6 The payment method based on a large model shown in this specification also provides embodiments. Figure 10 The diagram shows the structure of the electronic device. Figure 10At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile storage into memory and then runs it to implement the aforementioned payment method based on a large model.
[0116] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.
Claims
1. A payment system based on a large model, the system comprising: The system comprises an intelligent agent, a merchant system, and a payment server; the intelligent agent is located on the mobile terminal, and the mobile terminal has a payment client corresponding to the payment server installed; wherein: In response to a user's request to make a payment through the payment server, the intelligent agent generates contract parameters based on the user's intelligent agent account and sends the contract parameters to the payment server through the payment client. The payment server generates a user authorization identifier for querying the user's payment account based on the payment account currently logged in by the payment client, binds the generated user authorization identifier to the received smart agent account, generates contract information based on the binding relationship between the user authorization identifier and the smart agent account, and returns the contract information to the smart agent. The intelligent agent stores the contract information and, when interacting with the user through a pre-set large language model, identifies that the user has a purchase intention for the target product sold in the merchant system, instructs the payment server to make payment for the payment order generated for the target product through the user authorization identifier in the contract information.
2. The payment system as described in claim 1, wherein the intelligent agent is specifically used to, when recognizing that the user has a purchase intention for a target product sold in the merchant system, send a first order instruction for the target product to the merchant system; The merchant system is specifically used to send a second order instruction to the payment server based on the amount to be paid for the target product after receiving the first order instruction sent by the intelligent agent. The payment server is specifically used to generate a payment order upon receiving the second order placement instruction, and to return the order identifier of the payment order to the smart agent through the merchant system; The intelligent agent is specifically used to send the user's user authorization identifier to the payment server when it receives the order identifier.
3. The payment system as described in claim 2, wherein the intelligent agent integrates the payment SDK corresponding to the payment server; Specifically, the intelligent agent is used to, upon receiving the order identifier, invoke the payment SDK and send the user's user authorization identifier to the payment server through the API corresponding to the payment server contained in the SDK.
4. The payment system as described in claim 3, wherein the payment server is specifically configured to query the payment account corresponding to the received user authorization identifier, and return a response message to the payment SDK in the intelligent agent; Specifically, the intelligent agent is used to collect the user's identity information and send the identity information to the payment server when it receives the response message through the payment SDK; The payment server verifies the user's identity based on the payment account and the received identity information, and upon successful verification, processes the payment for the order based on the payment account.
5. The payment system as described in claim 3, wherein the smart agent is specifically configured to query, through the payment SDK, the user authorization identifier bound to the smart agent account currently logged into the smart agent, and send the queried user authorization identifier to the payment server through the API corresponding to the payment server.
6. A payment method based on a large model, the method comprising: In response to a user's request to make a payment through the payment server, the intelligent agent generates contract parameters based on the user's intelligent agent account; The intelligent agent is located on a mobile terminal, and the mobile terminal is equipped with a payment client corresponding to the payment server. The signing parameters are sent to the payment server through the payment client, so that the payment server generates a user authorization identifier for querying the payment account based on the payment account currently logged in by the payment client, binds the generated user authorization identifier to the smart agent account in the received signing parameters, generates signing information based on the binding relationship between the user authorization identifier and the smart agent account, and returns the signing information to the smart agent; The intelligent agent receives and stores the contract information; When the large language model identifies that the user has the intention to purchase the target product sold in the merchant system, the payment server is instructed to make payment for the payment order generated for the target product through the user authorization identifier in the contract information.
7. The method as described in claim 6, wherein the user authorization identifier in the contract information is used to instruct the payment server to make payment for the payment order generated for the target product, specifically including: Send a first order instruction for the target product to the merchant system, so that the merchant system sends a second order instruction to the payment server based on the amount to be paid for the target product; Receive the order identifier of the payment order generated by the payment server according to the second order placement instruction; In response to the received order identifier, the user's user authorization identifier is sent to the payment server, enabling the payment server to use the payment account bound to the user authorization identifier to make payment for the payment order.
8. The method as described in claim 6, wherein the intelligent agent integrates at least one e-commerce SDK corresponding to a merchant system; The large language model identifies the user's purchase intent for the target products sold in the merchant system, specifically including: Using the large language model, the semantics of the user's interaction with the large language model are identified, and based on the semantics, the product type of the product required by the user is identified; Based on the description information of each e-commerce SDK, determine the merchant system corresponding to the e-commerce SDK that matches the identified product type, and use it as the target merchant system; Based on the API of the target merchant system contained in the e-commerce SDK corresponding to the target merchant system, obtain the product information of the product type sold by the target merchant system, and display the obtained product information on the interface where the large language model interacts with the user. The product corresponding to the product information selected by the user on the interface is identified as the target product that the user intends to purchase.
9. The method as described in claim 7, wherein the intelligent agent integrates a payment SDK corresponding to the payment server; In response to the received order identifier, the user's user authorization identifier is sent to the payment server, specifically including: In response to the received order identifier, the payment SDK is invoked; The user's authorization identifier is sent to the payment server via the API corresponding to the payment server included in the SDK.
10. The method as described in claim 6, wherein sending the user's user authorization identifier to the payment server specifically includes: Determine the currently logged-in agent account; Query the stored contract information bound to the smart agent account; Determine the user authorization identifier in the contract information that is bound to the smart agent account; Send the user authorization identifier to the payment server.
11. The method of claim 9, further comprising: The payment SDK receives a response message returned by the payment server after querying the payment account corresponding to the user authorization identifier based on the user authorization identifier; In response to the response message, the user's identity information is collected; The identity information is sent to the payment server, which then verifies the user's identity based on the payment account and the received identity information. Upon successful verification, the payment server processes the payment order based on the payment account.
12. A payment method based on a large model, the method comprising: The payment server receives the signing parameters sent by the smart agent through the payment client corresponding to the payment server, and the signing parameters include the smart agent account logged in by the smart agent; Both the intelligent agent and the payment client are installed on the mobile terminal; the contract parameters are sent by the intelligent agent in response to the user's request to make a payment through the payment server. Generate a user authorization identifier for querying the payment account based on the payment account currently logged in to the payment client; Bind the user authorization identifier to the smart agent account included in the contract parameters; Based on the binding relationship between the user authorization identifier and the smart agent account, contract information is generated; The signing information is returned to the smart agent storage via the payment client; When the payment server receives the user authorization identifier sent by the intelligent agent, it uses the payment account corresponding to the user authorization identifier to pay for the payment order generated for the target product. The target product is the product that the intelligent agent identifies as having the user's purchase intention through a large language model.
13. The method as described in claim 12, wherein payment is made for the payment order generated for the target product using the payment account corresponding to the user authorization identifier, specifically including: The payment server receives order placement instructions from the merchant's system; The order placement instruction is a command sent by the intelligent agent to the merchant system when the agent interacts with the user through a pre-set large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. In response to the order placement instruction, a payment order is generated that includes the merchant's payment account and the amount to be paid; The order identifier of the payment order is returned to the intelligent agent through the merchant system; Receive the user authorization identifier of the user returned by the intelligent agent in response to the triggering of the order identifier; The payment order is processed based on the received user authorization identifier.
14. The method as described in claim 13, wherein payment is made for the payment order based on the received user authorization identifier, specifically comprising: Based on the received user authorization identifier, query the payment account bound to the user authorization identifier and return a response message to the intelligent agent; Receive the user's identity information collected and sent by the intelligent agent in response to the response message; The user is authenticated based on the payment account and the received identity information; Upon successful verification, payment is made to the payment order based on the payment account.
15. A payment device based on a large model, the device being located on a mobile terminal, the device comprising: The signing module responds to user requests to make payments through the payment server by generating signing parameters based on the user's smart agent account. The mobile terminal is equipped with a payment client corresponding to the payment server; the signing parameters are sent to the payment server through the payment client, so that the payment server generates a user authorization identifier for querying the payment account based on the payment account currently logged in by the payment client, and binds the generated user authorization identifier with the smart agent account in the received signing parameters, and generates and returns signing information based on the binding relationship between the user authorization identifier and the smart agent account; Receive the contract information and store it; The interaction module is used to instruct the payment server to make payment for the payment order generated for the target product when the user's intention to purchase the target product is identified by the large language model.
16. A payment device based on a large model, the device comprising: The signing module is used to receive signing parameters sent by the intelligent agent through a payment client corresponding to the payment server. The signing parameters include the intelligent agent account logged in by the intelligent agent. Both the intelligent agent and the payment client are installed on a mobile terminal. The signing parameters are sent by the intelligent agent in response to a user's request to make a payment through the payment server. Based on the payment account currently logged in by the payment client, a user authorization identifier is generated for querying the payment account. The user authorization identifier is then bound to the intelligent agent account included in the signing parameters. Based on the binding relationship between the user authorization identifier and the smart agent account, contract information is generated; The signing information is returned to the smart agent storage via the payment client; The receiving module is used to receive order placement instructions sent by the merchant's system; The order placement instruction is a command sent by the intelligent agent to the merchant system when the agent interacts with the user through a pre-set large language model and identifies that the user has the intention to purchase the target product sold in the merchant system. The payment module is used to pay for the payment order generated for the target product by using the payment account corresponding to the user authorization identifier when receiving the user authorization identifier sent by the intelligent agent. The target product is the product that the user has the intention to purchase, as identified by the intelligent agent through a large language model.
17. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 6-14.
18. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method of any one of claims 6-14.