Payment processing method and device, equipment, medium and program product

Abstract

The embodiment of the invention discloses a payment processing method and device, equipment, a medium and a program product. The method comprises the following steps: when N social contact objects carry out collaborative payment on bills, displaying sub-bills allocated to each social contact object; receiving a confirmation operation executed by the target social contact object for the corresponding target sub-bill; and after the N social contact objects execute confirmation operation on the distributed sub-bills, receiving payment operation executed by the target social contact object on the target sub-bills. By adopting the embodiment of the invention, the intelligence, interactivity and fairness of bill allocation in a multi-person common consumption scene can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to the field of payment processing, specifically to a payment processing method, a payment processing device, a computer equipment, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the development of internet technology, mobile payment via the internet has become increasingly popular, making the issues of bill sharing and settlement in scenarios where multiple people consume together increasingly prominent.

[0003] Currently, the traditional method of bill sharing involves one user paying the bill, and then that user initiating the sharing of the bill with other users by either dividing it equally or manually entering the amount to be shared. This method requires frequent switching between pages or even the entire application, which is not only complex and time-consuming but also fails to ensure the fairness of bill sharing. Therefore, how to achieve intelligent bill sharing in scenarios involving multiple users has become a research hotspot. Summary of the Invention

[0004] This application provides a payment processing method, apparatus, device, medium, and program product to improve the intelligence, interactivity, and fairness of bill sharing in scenarios involving multiple people sharing consumption.

[0005] On one hand, embodiments of this application provide a payment processing method, the method comprising:

[0006] When N social contacts collaboratively pay a bill, the sub-bill assigned to each social contact is displayed. The total resource limit of the N sub-bills equals the resource limit of the bill; N is an integer greater than 1.

[0007] Receive confirmation from the target social object for the corresponding target sub-bill; the target social object is any one of N social objects, and the target sub-bill is the sub-bill assigned to the target social object among the N sub-bills;

[0008] After N social objects have confirmed their respective assigned sub-bills, the payment operation performed by the target social object on the target sub-bill is received.

[0009] On the other hand, embodiments of this application provide a payment processing apparatus, which includes:

[0010] The display unit is used to display the sub-bill assigned to each social object when N social objects make collaborative payments for a bill. The total resource limit of the N sub-bills is equal to the resource limit of the bill; N is an integer greater than 1.

[0011] The processing unit is used to receive the confirmation operation performed by the target social object for the corresponding target sub-bill; the target social object is any one of N social objects, and the target sub-bill is the sub-bill assigned to the target social object among the N sub-bills;

[0012] The processing unit is also used to receive the payment operation performed by the target social object on the target sub-bill after N social objects have performed confirmation operations on their respective assigned sub-bills.

[0013] In one implementation, the processing unit, when receiving a payment operation performed by the target social object on the target sub-bill, is specifically used for:

[0014] The payment interface is displayed, which includes security assessment information. This information is used to characterize the payment security level of the target social object; different payment security levels correspond to different payment methods.

[0015] Receive payment operations from the target social object for the target sub-bill according to the payment method corresponding to the payment security level;

[0016] Output the payment results interface, which displays the payment progress information for each social contact's assigned sub-bill.

[0017] In one implementation, the target social object is the first social object among N social objects to initiate collaborative payment for a bill, and the social objects other than the first social object among the N social objects are represented as the second social objects; the processing unit, used to display the sub-bills assigned to each social object when N social objects make collaborative payments for a bill, specifically is used for:

[0018] In response to the bill viewing operation, the bill interface is displayed; the bill interface includes bill details and a collaborative payment entry point;

[0019] In response to a triggered action on the collaborative payment entry point, the collaborative payment interface is displayed, which includes object identifiers for N social objects;

[0020] Based on the bill allocation operation performed in the collaborative payment interface, the sub-bills assigned to each social object are displayed.

[0021] In one implementation, the processing unit, in response to a triggered operation on the collaborative payment entry point, displays the collaborative payment interface, specifically for:

[0022] In response to a triggered action on the collaborative payment entry point, the collaborative payment interface is displayed, which includes an object addition area;

[0023] In response to an object addition operation performed in the object addition area, display the object identifier of each of the N social objects in the object addition area;

[0024] The object addition operation includes at least one of the following: a selection operation performed on an object identifier from an object list, a selection operation on a recommended social object, a sharing operation to join the payment group to which the first social object belongs by sharing an invitation message, and an input operation on the object identifier of the social object.

[0025] In one implementation, the collaborative payment interface includes a recommendation allocation strategy, which defines the allocation rules for distributing bills among N social objects based on their consumption information; and a processing unit, used to display the sub-bills allocated to each social object based on the bill allocation operation performed in the collaborative payment interface, specifically for:

[0026] The recommended allocation strategy is displayed in the collaborative payment interface;

[0027] In response to the selection of the recommended allocation strategy, the sub-bills assigned to each social object are displayed; the N sub-bills are obtained by allocating the bills according to the allocation rules defined by the recommended allocation strategy.

[0028] In one implementation, the collaborative payment interface includes strategy configuration options and a processing unit. Specifically, when displaying the sub-bills assigned to each social object based on the bill allocation operation performed within the collaborative payment interface, the processing unit is used for:

[0029] When the policy configuration option is triggered, the policy configuration interface is displayed;

[0030] It receives the strategy configuration operation executed in the strategy configuration interface and displays the sub-bills assigned to each social object; the N sub-bills are obtained by allocating the bills based on the setting allocation strategy generated by the strategy configuration operation.

[0031] In one implementation, each social object corresponds to an intelligent agent, which is used to negotiate bill allocation on behalf of the social object; the collaborative payment interface also includes an allocation negotiation area; and a processing unit, used to display the sub-bills allocated to each social object, specifically for:

[0032] In the allocation negotiation area, the allocation suggestion information sent by each agent is displayed in the form of a session message; the target allocation suggestion information sent by the agent corresponding to the first social object is the recommended allocation strategy and / or the setting allocation strategy; the allocation suggestion information sent by the agent corresponding to any second social object among the N social objects (excluding the first social object) is generated from multiple evaluation dimensions, including the fairness dimension and the consumption habit dimension.

[0033] When the bill allocation negotiation ends, the collaborative payment interface displays N sub-bills obtained by allocating the bill based on the reference allocation strategy; the reference allocation strategy is generated based on the allocation suggestion information sent by N agents.

[0034] In one implementation, the collaborative payment interface also includes an adjustment component and a processing unit, which are further used for:

[0035] In response to the triggering operation of the adjustment component, the strategy configuration interface is displayed; the strategy configuration interface includes at least one strategy configuration item, one strategy configuration item corresponds to one consumption item, and the strategy configuration item displays the corresponding configuration information in the reference allocation strategy;

[0036] Based on the adjustments made to the policy configuration items in the policy configuration interface, N first fine-tuned sub-bills are displayed, which are obtained by allocating the bills based on the adjusted reference allocation policy.

[0037] The processing unit, when receiving confirmation operations performed by the target social object for the corresponding target sub-bill, is specifically used for:

[0038] Receive confirmation from the target social object for the target sub-bill among N first-fine-tuning sub-bills.

[0039] In one implementation, any social object among N social objects other than the first social object is represented as the second social object; the processing unit is further configured to:

[0040] Send N sub-bills to each second social object; and,

[0041] The confirmation waiting screen displays the confirmation progress information for each social object regarding its assigned sub-bill.

[0042] If strategy modification information related to the second social object is displayed in the confirmation waiting interface, the strategy configuration interface is displayed in response to the receiving operation of the strategy modification information. The strategy configuration interface includes at least one strategy configuration item, one strategy configuration item corresponds to one consumption item, and the strategy configuration item displays the corresponding configuration information in the reference allocation strategy. The target strategy configuration item related to the strategy modification information is highlighted in the strategy configuration interface.

[0043] In response to a policy fine-tuning operation on a target policy configuration item, display N second fine-tuning sub-bills obtained by allocating the bills based on the fine-tuning allocation policy generated by the policy fine-tuning operation.

[0044] In response to confirmation operations for N second-fine-tuning sub-bills, a confirmation waiting screen is displayed.

[0045] In one implementation, the progress information includes: confirmed, awaiting confirmation, and unconfirmed; the processing unit is further configured to:

[0046] When the confirmation progress information of the second social object for the assigned sub-bill is "awaiting confirmation" or "not confirmed", and the confirmation progress duration is greater than the duration threshold, a confirmation reply window will be displayed in the confirmation waiting interface. The confirmation reply window includes confirmation reply information, which is used to characterize the predicted feedback time of the second social object for the sub-bill. The confirmation reply window also includes confirmation prompt options.

[0047] In response to the triggering of the confirmation prompt option, a prompt message is sent to the second social object. The prompt message is used to prompt the second social object to confirm the bill or set the policy modification information for the assigned sub-bill.

[0048] In one implementation, the processing unit is further used for:

[0049] Obtain target allocation suggestion information and receive allocation suggestion information sent by the agents corresponding to each second social object in response to the target allocation suggestion information;

[0050] Based on the allocation suggestion information and the target allocation suggestion information, the strategy is integrated and processed to generate a reference allocation strategy.

[0051] In one implementation, when the target allocation suggestion information is a recommended allocation strategy, the processing unit, when obtaining the target allocation suggestion information, specifically performs the following:

[0052] Obtain consumption information from each secondary social contact;

[0053] Based on the message information of each of the N social objects, predict the association information between each social object and the bill;

[0054] Obtain the target allocation pattern and generate a recommended allocation strategy based on the associated information and the target allocation pattern.

[0055] In one implementation, the processing unit, when predicting the association information between each social object and the bill based on the message information of each of the N social objects, specifically performs the following:

[0056] Perform scenario analysis on the consumption scenario to which the bill belongs, and obtain the scenario analysis results;

[0057] Based on the scenario analysis results, the social relationship information between N social objects and the behavioral pattern information of each social object, the identity information of each social object in the consumption scenario is identified.

[0058] Obtain at least one consumption item associated with the bill, and establish association information between each social object and each consumption item based on the identity information and message information corresponding to each social object, as well as the item characteristics of each consumption item; any association information includes matching information between the social object and the consumption item.

[0059] In one implementation, the target social object is the second social object among N social objects participating in the collaborative payment of the bill; the processing unit, used to display the sub-bill assigned to each social object when N social objects make collaborative payments for the bill, specifically performs the following:

[0060] When N objects make collaborative payments on a bill, a message receiving interface is displayed, which includes allocation messages related to the bill.

[0061] In response to viewing the assigned message, the bill confirmation interface is displayed; the bill confirmation interface includes the sub-bill assigned to each social object, as well as the confirmation progress information for each sub-bill.

[0062] In one implementation, the bill confirmation interface includes a modification component, a processing unit, and is also used for:

[0063] When the modification component is triggered, the modification interface is displayed. The modification interface includes: each consumption item associated with the bill, and a modification description area for each consumption item.

[0064] If any consumer item is selected, receive the policy modification information entered in the modification description area corresponding to any consumer item;

[0065] In response to the submission of policy modification information, a notification message is output, which indicates that the first social object should be waited for to resend the sub-bill.

[0066] On the other hand, embodiments of this application provide a computer device, the device comprising:

[0067] A processor is used to load and execute computer programs;

[0068] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the payment processing method described above.

[0069] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the above-described payment processing method.

[0070] On the other hand, embodiments of this application provide a computer program product, which includes computer instructions that, when executed by a processor, implement the payment processing method described above.

[0071] In this embodiment, when N social media users collaboratively pay a bill, the system first displays the sub-bills assigned to each of the N users. The total resource limit of each of the N sub-bills equals the resource limit of the bill, thus achieving bill sharing among the N users. Then, after each user previews their assigned sub-bills, each user needs to confirm their sub-bills, greatly enhancing interactivity during bill sharing and ensuring that each user agrees on the reasonableness of the bill allocation. After all N users confirm their assigned sub-bills, the system can receive payment operations from the target social media user for the target sub-bills. Specifically, it receives payment operations from each user for their assigned sub-bills, thus achieving settlement of each sub-bill and achieving bill sharing. As described above, on the one hand, in multi-person consumption scenarios, the bill to be paid is intelligently split directly, eliminating the need for a single payment bill. This improves the intelligence of bill splitting, and the resulting N sub-bills are directly shared with N social contacts in the multi-person consumption scenario. This allows each social contact to view their own and others' sub-bills, achieving openness and transparency in bill allocation. On the other hand, the bill allocation process includes a confirmation step for each social contact regarding the sub-bills, increasing interactivity among social contacts in multi-person consumption scenarios. This interactivity provides social contacts with an entry point to submit objections to sub-bills, thereby significantly improving the fairness of bill allocation. Attached Figure Description

[0072] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, 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.

[0073] Figure 1a This is a schematic diagram of the architecture of a payment processing system provided in an exemplary embodiment of this application;

[0074] Figure 1b This is a schematic diagram of the architecture of another payment processing system provided in an exemplary embodiment of this application;

[0075] Figure 2 This is a schematic flowchart of a payment processing method provided in an exemplary embodiment of this application;

[0076] Figure 3 This is a schematic diagram illustrating the display of N sub-bills provided in an exemplary embodiment of this application;

[0077] Figure 4 This is a schematic diagram illustrating a payment operation on a target sub-bill provided in an exemplary embodiment of this application;

[0078] Figure 5 This is a schematic diagram of a social relationship strength analysis process provided in an exemplary embodiment of this application;

[0079] Figure 6 This is a schematic diagram of a process for determining a security policy provided in an exemplary embodiment of this application;

[0080] Figure 7 This is a flowchart illustrating another payment processing method provided in an exemplary embodiment of this application;

[0081] Figure 8 This is a schematic diagram illustrating a bill interface displayed based on a bill viewing operation, provided by an exemplary embodiment of this application;

[0082] Figure 9a This is a schematic diagram illustrating a trigger operation performed on a collaborative payment entry point, provided by an exemplary embodiment of this application.

[0083] Figure 9b This is a schematic diagram illustrating a method for determining recommended social objects, provided in an exemplary embodiment of this application.

[0084] Figure 9c This is an exemplary embodiment of the present application illustrating an invitation to a social object via invitation information;

[0085] Figure 9d This is a schematic diagram illustrating an exemplary embodiment of this application of inviting social objects by inputting an object identifier;

[0086] Figure 10a This is a schematic diagram illustrating a method for selecting a recommended allocation strategy for bill splitting, provided by an exemplary embodiment of this application.

[0087] Figure 10b This is a schematic diagram illustrating reinforcement learning for an intelligent agent, provided in an exemplary embodiment of this application.

[0088] Figure 11 This is a schematic diagram of a first social object custom setting allocation strategy provided in an exemplary embodiment of this application;

[0089] Figure 12This is a schematic diagram illustrating a bill splitting method using a reference allocation strategy, provided in an exemplary embodiment of this application.

[0090] Figure 13 This is a schematic diagram illustrating a fine-tuning of a reference allocation strategy provided in an exemplary embodiment of this application;

[0091] Figure 14 This is a technical implementation framework diagram of an identity recognition and reference allocation strategy provided by an exemplary embodiment of this application;

[0092] Figure 15 This is a schematic diagram of multi-agent negotiation provided in an exemplary embodiment of this application;

[0093] Figure 16 This is a schematic diagram illustrating a first social object performing a confirmation operation on N sub-bills, provided in an exemplary embodiment of this application.

[0094] Figure 17 This is a schematic diagram of a confirmation reply window provided in an exemplary embodiment of this application;

[0095] Figure 18 This is a schematic diagram illustrating how a first social object receives policy modification information sent by a second social object and performs fine-tuning of a reference allocation policy, according to an exemplary embodiment of this application.

[0096] Figure 19 This is a flowchart illustrating yet another payment processing method provided in an exemplary embodiment of this application;

[0097] Figure 20 This is a schematic diagram of a bill confirmation interface displayed on a second social object side, provided by an exemplary embodiment of this application;

[0098] Figure 21 This is a schematic diagram illustrating the editing of strategy modification information by a second social object, provided in an exemplary embodiment of this application.

[0099] Figure 22 This is a flowchart illustrating another payment processing method provided in an exemplary embodiment of this application;

[0100] Figure 23 This is a schematic diagram of the structure of a payment processing device provided in an exemplary embodiment of this application;

[0101] Figure 24 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application. Detailed Implementation

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

[0103] This application proposes a payment processing scheme, specifically an AI-assisted scheme that enables collaborative payments between multiple social entities. The following is a brief introduction to the technical terms and related concepts involved in the payment processing scheme provided in this application embodiment:

[0104] I. Multi-person Collaborative Payment.

[0105] Multi-user collaborative payment refers to the process in which multiple users jointly share and settle the bills generated in a consumption scenario. Through multi-user collaborative payment, in a consumption scenario where multiple people shop together, multiple users can directly share and settle the bills generated in the consumption scenario, without one user first settling the bill and then that user initiating payment collection from the other users.

[0106] In the application embodiment, users participating in a multi-person consumption scenario are referred to as social objects. Assuming the number of social objects is N, where N is an integer greater than 1, meaning N social objects are users jointly participating in the consumption scenario. The bill information generated in the consumption scenario includes resource limit, consumption type, and consumption time. The resource limit refers to the payment amount corresponding to the bill, such as a payment amount of 100 yuan stated in the bill. The consumption type refers to the type of consumption categorized according to consumption purpose or transaction method. For example, categorized by consumption purpose, consumption types can include, but are not limited to, dining out, group buying, utility bills, and online shopping. During multi-person collaborative payment, the bill generated in the consumption scenario is split into N sub-bills. Each sub-bill is assigned to one social object, and the sum of the resource limits of the N sub-bills equals the resource limit of the bill. In other words, the sum of the resource limits of each of the N sub-bills is the same as the resource limit of the bill, achieving the purpose of sharing the bill's resource limit among the N social objects.

[0107] II. Artificial Intelligence.

[0108] Artificial intelligence (AI) is the theory, methods, technology, and application systems that use digital computers or computers-controlled machines to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. The fundamental technologies of AI generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. The software technologies of AI mainly include computer vision, speech processing, natural language processing, and machine learning (ML) / deep learning.

[0109] This application primarily relates to machine learning within the field of artificial intelligence. Machine learning is a multidisciplinary field involving probability theory, statistics, approximation theory, convex analysis, algorithm complexity theory, and many other disciplines; it specifically studies how computers can simulate or implement human learning behavior to acquire new knowledge or skills and reorganize existing knowledge structures to continuously improve their performance. This application primarily relates to reinforcement learning (RL) and graph neural networks (GNN) within the field of machine learning. Reinforcement learning is a machine learning method that optimizes the decision-making process by interacting with the environment and learning from feedback. Graph neural networks are machine learning models used to process graph data; the input data of a graph neural network is graph-structured data, including vertex information (feature vectors of each node) and edge information (describing the relationships between nodes), enabling it to model nodes, edges, or the entire graph and learn its inherent structural information and feature representations.

[0110] Currently, bill sharing methods in multi-person shared consumption scenarios are relatively fixed, lacking intelligence and even fairness. Traditional bill sharing methods include: ① Bill sharing through equal distribution and custom amount modes; specifically, bills are automatically split equally, or a social user manually enters the amount each social user needs to pay. Both equal distribution and custom amount modes require one social user to pay the bill first, then the bill's resource allocation is split using the equal distribution or custom amount mode, and the split sub-bills are sent to other social users for payment. This requires the social user initiating bill sharing to switch between multiple interfaces or applications, requiring steps such as identity verification, bill allocation, and payment verification, resulting in complex operations and inconsistent user experience. ② Bill sharing within groups based on user relationships; specifically, users pre-create and manage fixed sharing groups, such as "family" or "roommates" groups. When members within a group send collaborative payment requests, the bill is shared among the group members. This bill sharing method based on group management prevents users from different groups from sharing bills, which greatly limits the scenarios in which collaborative payment can be applied.

[0111] Based on this, the payment processing solution provided in this application aims to comprehensively improve the intelligence, interactivity, and fairness of bill allocation from aspects such as a two-stage allocation mode, an intelligent bill allocation mode, and a social relationship verification mode, thereby addressing the shortcomings of traditional bill allocation methods. These three modes are briefly introduced below and will be elaborated in detail in subsequent specific embodiments.

[0112] (1) Two-stage sharing model.

[0113] The two-stage cost-sharing model refers to the following: After splitting the bill into N sub-bills, each of the N social participants first confirms their assigned sub-bills, primarily to verify the reasonable allocation of resources within each sub-bill. Once all social participants have confirmed their assigned sub-bills, each of the N participants then executes payment for their respective sub-bills, thus completing the cost-sharing and settlement. This two-stage model provides each social participant in a multi-person consumption scenario with a channel or means to raise objections to their assigned sub-bills. If any social participant objects to their assigned sub-bill, the bill will be re-split, effectively ensuring the reasonableness of the bill split and maximizing the satisfaction of each social participant with the cost-sharing.

[0114] The process of achieving collaborative payment among multiple users based on a two-stage cost-sharing model can be roughly summarized as follows: When N social users collaboratively pay for a bill, each user's terminal displays the N sub-bills assigned to them. Then, a confirmation operation is received from the target social user (any one of the N social users), and the target sub-bill is the one assigned to that user. Finally, after all N social users have confirmed their assigned sub-bills, the payment operation from the target social user for the target sub-bill can be received; once all social users have successfully completed their payment operations, bill settlement can be achieved.

[0115] (2) Intelligent bill sharing mode.

[0116] Intelligent bill allocation refers to a method based on intelligent agents that uses intelligent bill splitting to allocate sub-bills to each social entity. Specifically, intelligent bill splitting (Intelligent Bill Splitting) is a technology that automatically generates a reasonable bill allocation strategy based on at least one associated consumption item, the consumption information of the social entity (such as consumption preferences), and social relationships.

[0117] An intelligent agent is an intelligent system equipped for social participants, capable of performing functions such as payment decisions, negotiation, and security assessments on their behalf. This intelligent system can be broadly categorized into virtual intelligent agents (such as software programs capable of payment decisions, negotiation, and security assessments) and object intelligent agents (such as robots or other automated devices capable of payment decisions, negotiation, and security assessments). In this embodiment, by retaining payment data for each payment made by the social participant (such as the bill allocation strategy used in collaborative payments, and the social participant's consumption preferences), and utilizing this payment data in conjunction with the aforementioned reinforcement learning, the intelligent agent's autonomous learning and decision-making capabilities are continuously optimized. This enables the intelligent agent to provide more suitable splitting suggestions in the bill allocation negotiation process, thereby promoting the rationality of bill sharing.

[0118] In this embodiment, each social object is equipped with a personalized intelligent agent. Each intelligent agent learns the payment habits, social preferences, and consumption patterns of the corresponding social object, enabling it to proactively provide splitting suggestions (also known as allocation suggestions) in the background bill splitting process on behalf of the social object. This achieves negotiation and game theory in the bill splitting process, automatically reaching the optimal bill allocation strategy, thereby optimizing the rationality of bill splitting.

[0119] (3) Social relationship verification model.

[0120] The social relationship verification model refers to constructing a social network among N social objects and analyzing this network using the aforementioned graph neural network. Specifically, it analyzes the strength of social relationships among the N social objects to accurately predict the social trust score between them. The social trust score is used to assess the degree of trust between social objects. A higher social trust score can simplify verification when social objects perform payment operations on sub-bills, thereby improving the speed of payment.

[0121] A social network is a network used to describe the relationship structure between social objects in a society. This social network can be constructed as a graph structure composed of nodes and edges using a graph neural network. In this embodiment, the social network specifically refers to the relationship network formed by N social objects in an application with payment functionality. The social tie strength between social objects is an indicator that quantifies the closeness of the social relationship between two social objects. It can be calculated from multiple dimensions such as interaction frequency, intimacy, and reciprocity between the two social objects; for example, the higher the interaction frequency, the greater the social tie strength between the social objects. The social trust score is a trust index calculated based on the social tie strength and historical transaction behavior, used to assess the degree of trust between two social objects. Simplified verification refers to a mechanism that appropriately simplifies the payment verification process based on the degree of social trust between social objects.

[0122] The payment processing solution provided in this application is a multi-person collaborative payment solution for bill sharing and settlement among multiple social objects, and flexibly changes the verification process according to the strength of the social relationship between the social objects. It can be applied to various consumption scenarios that require multi-person collaborative payment. Consumption scenarios can include, but are not limited to, dining scenarios, group buying scenarios, travel scenarios, and daily payment scenarios. Among them: ① Dining scenario: It supports intelligent generation of bill allocation strategies based on the ordering habits of each social object when dining together, so as to split the bill generated in the dining scenario. This ensures that each social object in the dining scenario only pays for the food and drinks they consume, based on the correlation between the social object and the consumption items (such as staple food, drinks, and seafood) associated with the bill generated in the dining scenario. ② Group buying scenario: It supports intelligent generation of bill allocation strategies based on the type and quantity of goods purchased by each social object when participating in group buying, so as to split the bill generated in the group buying scenario. This ensures that each social object in the group buying scenario only pays for the corresponding quantity of goods they purchased, avoiding payment for unreasonable consumption items. ③ Travel Scenarios: Supports reasonable cost allocation and settlement of bills based on each social user's consumption items during travel (such as attraction tickets, hotel accommodations, etc.), improving the fairness of bill allocation among social users in travel scenarios. ④ Daily Payment Scenarios: Such as utility bill settlement, rent settlement, and parking fee settlement scenarios, using the payment processing solution provided in this application embodiment in these daily payment scenarios can effectively ensure that each social user only needs to pay the amount of their own consumption items. Therefore, using the payment processing solution provided in this application embodiment in various consumption scenarios can significantly improve the intelligence of bill splitting and ensure the rationality and fairness of bill allocation.

[0123] Furthermore, the payment processing solution provided in this application embodiment can be applied to applications with payment functions. An application refers to a computer program designed to complete one or more specific tasks. Classifying applications according to their functions, applications capable of integrating the payment processing solution provided in this application embodiment can include, but are not limited to: ① Payment applications, which are dedicated payment applications that act as trusted intermediaries between both parties in a transaction, effectively ensuring fund security; by integrating the payment processing solution provided in this application embodiment into a payment application, it can be ensured that collaborative payments can be efficiently achieved in any multi-person consumption scenario implemented based on the payment application. ② Social applications, which are applications that enable instant messaging and social interaction based on the internet; providing the payment processing solution provided in this application embodiment in a social application can ensure a balance between transaction payment security and computational performance in the social application, achieving secure payment during social conversations while ensuring that payment overhead performance does not affect social functions. Applications can be categorized according to their operating methods. Applications capable of integrating the payment processing solution provided in this application's embodiments may include, but are not limited to: ① clients that require downloading and installing an installation package to run on a terminal; ② mini-programs that can be used without downloading and installing, typically as sub-programs of the client; ③ web (World Wide Web) applications opened through a browser, etc. The following explanation will use the integration of the payment processing solution provided in this application's embodiments into a social application (such as a social client) as an example.

[0124] It should be understood that the above description is merely an exemplary product performance and information search scenario provided by the embodiments of this application, and does not limit the product performance and consumption scenarios of the payment processing solution provided by the embodiments of this application. The payment processing solution provided by the embodiments of this application can provide a balance between security and computing performance in various consumption scenarios, demonstrating high value and practicality in various consumption scenarios, and helping to improve user experience and satisfaction.

[0125] To facilitate understanding of the payment processing scheme provided in the embodiments of this application, the following is combined with... Figure 1a The illustrated scenario provides a brief overview of the consumption scenarios involved in the embodiments of this application; for example... Figure 1a As shown, the system includes terminal 101, terminal 102, terminal 103 and server 104. The embodiments of this application do not limit the number and naming of terminal 101, terminal 102, terminal 103 and server 104.

[0126] In this embodiment, terminals 101, 102, and 103 are terminals held by social objects that need to share the bill, such as social object 1 holding terminal 101, social object 2 holding terminal 102, and social object 3 holding terminal 103. Each terminal has an application of the aforementioned integrated payment processing solution, such as a social application, deployed and running, so that the terminals can share and settle the bill through the social application. The terminals include, but are not limited to, smartphones (such as smartphones running Android or smartphones running Internetworking Operating System (IOS), tablets, portable personal computers, mobile Internet Devices (MIDs), in-vehicle devices, head-mounted devices, intelligent chatbots, and aircraft, etc. This application embodiment does not limit the type of terminal, which is stated herein.

[0127] Server 104 is the server corresponding to the terminal, used to interact with the terminal to provide computing and application service support. The terminal here refers to the aforementioned terminals 101, 102, and 103. Specifically, server 104 is a backend service corresponding to the application deployed on the terminal, providing the technical support and services required for bill sharing through the terminal. Specifically, server 104 deploys an intelligent agent corresponding to each social object, enabling these agents to negotiate and process bill sharing through server 104. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0128] The payment processing system comprises various devices that can communicate directly or indirectly via wired or wireless means. This application embodiment does not limit the communication methods between devices; for example, communication methods between devices may include, but are not limited to, HTTP requests, Remote Procedure Calls, sockets, and content sharing. The payment processing scheme provided in this application embodiment can be executed by a computer device, which may include… Figure 1aThe system shown includes terminals (such as terminals 101, 102, and 103) and server 104, or includes one of terminals (terminal 101, 102, or 103) and server 104. This application embodiment does not limit the executing entity of the payment processing scheme. The following example illustrates the joint execution of the payment processing scheme by terminals and server 104. Figure 1a The payment processing system shown provides a brief overview of the solution process.

[0129] In a multi-person consumption scenario, when N social entities need to collaboratively pay for a bill, each social entity's terminal (e.g., terminal 101, terminal 102, and terminal 103) will be issued N sub-bills by server 104. Each social entity can then confirm its assigned sub-bills through the N sub-bills displayed on its various terminals. For example, any social entity among the N social entities—the target social entity—can confirm its assigned sub-bills—the target sub-bills. Of course, social entities can also object to their assigned bills. When a social entity objects, server 104 will readjust the bill allocation strategy to redistribute the bills, and the N social entities will reconfirm the new N sub-bills until all N social entities have confirmed their respective assigned sub-bills. Thus, after N social objects confirm their assigned sub-bills, it is determined that N social objects have no objection to the allocation of this bill. At this point, each social object can perform a payment operation on its assigned sub-bills through various terminals to complete the allocation and settlement of this bill.

[0130] Based on the above brief introduction of the payment processing scheme and payment processing system provided in the embodiments of this application, the following points should also be noted:

[0131] ①The embodiments of this application mentioned above Figure 1a The schematic diagram shown is for illustrative purposes only and does not constitute a limitation on the technical solutions provided in the embodiments of this application. Those skilled in the art will recognize that, with the evolution of architectures and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems. That is to say, Figure 1a The schematic diagram of the consumption scenario shown is an exemplary schematic diagram; in actual applications, the number and types of devices included in the consumption scenario may vary, and the schematic diagram of the consumption scenario in this application embodiment is not limited.

[0132] For example, suppose the agents corresponding to N social objects may be deployed on different servers; Figure 1bAs shown, the payment processing system includes N servers (104 in total). Each server deploys one intelligent agent to provide technical services and support. The process of bill negotiation between multiple intelligent agents is the process of data interaction between multiple servers. Furthermore, if N social objects receive the N sub-bills assigned to them at different times, the direction and order of data flow between the terminal and the server in the payment processing system will differ; for example... Figure 1b As shown, assuming social object 1 is the initiator of the collaborative payment, social object 1 first receives N sub-bills from the server. Only after social object 1 confirms its own sub-bills will the server send the N sub-bills to the participants in the collaborative payment, namely social object 2 and social object 3, for confirmation. This collaborative payment process will be described in detail in subsequent embodiments, but is only explained here.

[0133] ② The data collection and processing in this application embodiment should strictly comply with the requirements of relevant laws and regulations. Obtaining personal information requires the knowledge or consent of the individual (or a legal basis for information acquisition), and subsequent data use and processing should be carried out within the scope of laws, regulations, and the authorization of the personal information subject. For example, when this application embodiment is applied to specific products or technologies, operations such as collecting messages from social media users are only performed when a collaborative payment is initiated by a social media user. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant regions.

[0134] Based on the payment processing scheme described above, this application proposes a more detailed payment processing method. The payment processing method proposed in this application will be described in detail below with reference to the accompanying drawings.

[0135] Please see Figure 2 , Figure 2 The illustration shows a flowchart of a payment processing method provided in an exemplary embodiment of this application. Figure 2 The payment processing method shown can be executed by a computer device. Taking the computer device as an example, which is a terminal held by the social participant, the payment processing method includes, but is not limited to, steps S201-S203:

[0136] S201: When N social objects collaborate on a bill payment, display the sub-bill assigned to each social object.

[0137] In a multi-person consumption scenario where N social individuals need to collaboratively pay a bill, the bill is split into N sub-bills for each of the N social individuals. The number of sub-bills is the same as the number of social individuals, N. These N sub-bills are shared with each social individual so that each individual can view their assigned sub-bills through their own device.

[0138] As mentioned above, this application embodiment supports splitting a bill into N sub-bills according to a bill allocation strategy. This bill allocation strategy defines the allocation rules for distributing the bill among N social objects, specifically including one or more allocation sub-rules. Each allocation sub-rule defines the allocation method for one of the at least one consumption item associated with the bill. The consumption item associated with the bill can be understood as a type of consumption that forms or generates the bill in a consumption scenario. For example, in a dining scenario, the consumption items associated with the bill may include: staple food items, seafood items, stir-fried dishes, and beverage items. Similarly, in a fruit group-buying scenario, the consumption items associated with the bill may include: apple items, banana items, and grape items. Based on this, assuming a multi-person consumption scenario is a dining scenario, an exemplary bill allocation strategy in a dining scenario might be: allocating the amount for staple food items according to an average allocation model, allocating the amount for seafood items according to an individual ordering model, and allocating the amount for beverage items according to an average allocation model.

[0139] To facilitate a clear and intuitive understanding of the basis for bill allocation among social users, this application embodiment supports displaying the allocation basis information of the bill in the same service interface (UI) while displaying the sub-bill assigned to each social user. This allocation basis information describes the bill allocation strategy and the specific breakdown of the bill according to the strategy (such as the amount corresponding to each consumption item, the amount each social user needs to pay for each consumption item, etc.). Figure 3 As shown, the first display area 301 of the service interface displays the sub-bills assigned to N social objects, and the second display area 302 displays the allocation basis information on which this bill allocation is based. By displaying N sub-bills and allocation basis information simultaneously in the same service interface, it is convenient for each social object to understand the principle of bill allocation, thereby helping the social object to better determine whether to raise objections to this bill allocation, improving the social object's understanding of the bill allocation situation, and thus improving the rationality and fairness of bill allocation.

[0140] S202: Receive confirmation from the target social object for the corresponding target sub-bill.

[0141] For ease of explanation, any one of the N social objects is referred to as the target social object, and the sub-bill assigned to the target social object is called the target sub-bill. That is, the target sub-bill is the sub-bill assigned to the target social object among the N sub-bills.

[0142] Specifically, after each social participant's assigned sub-bills are output on their respective devices, each participant can judge the reasonableness of the bill allocation based on their spending habits or preferences. For example, if a participant didn't order a main dish during a meal, but their sub-bill includes the cost of a main dish, they can determine that the bill allocation is unreasonable. If the participant determines the bill allocation is reasonable, they can confirm their assigned sub-bill, indicating their agreement to the allocation method. Conversely, if the participant determines the allocation is unreasonable, they can object and submit a policy modification request, allowing the backend to re-allocate the bill using a new allocation strategy.

[0143] S203: After N social objects have performed confirmation operations on their respective assigned sub-bills, receive the payment operation performed by the target social object on the target sub-bill.

[0144] Based on the description in step S202, when each social object confirms its assigned sub-bill, it indicates that each social object agrees to the bill allocation method. Then, a payment process for the sub-bill can be initiated. Specifically, each social object performs a payment operation on its assigned sub-bill resource limit on its own terminal. As shown in steps S202 and S203, this application embodiment provides a two-stage cost-sharing mode. When there is a dispute over bill allocation, it provides a mechanism for each social object to negotiate bill allocation, avoiding unnecessary friction caused by bill allocation. Compared to the existing bill allocation method where a single user unilaterally decides the bill allocation, this fully realizes the effect of negotiating or coordinating bill allocation among N social objects.

[0145] It's worth noting that security verification is an essential step in the payment process, effectively ensuring the security of data such as social contacts and payment funds. Existing bill-sharing technologies use the same verification process for each social contact, making it difficult to balance security and convenience. However, practical experience shows that if the social relationship between contacts is one of familiarity, such as two frequently interacting contacts, the strength of social trust between them is relatively high. In this case, based on the established social trust relationship, appropriately simplifying the verification process can provide a more convenient payment experience for payments between acquaintances.

[0146] Based on this, this application provides a social relationship verification mode based on a simplified verification process of social trust relationships, specifically a simplified verification mechanism based on social trust. This simplified verification mechanism supports dynamically adjusting the complexity of payment verification when different social objects perform payment operations based on the social trust scores between them, providing a simplified verification process for social objects with high social trust relationships and improving the payment experience. Correspondingly, the implementation process of the social relationship verification mode provided in this application on the user side may include: when the target social object pays for the target sub-bill, a payment interface is first displayed. This payment interface includes security assessment information, which characterizes the payment security level corresponding to the target social object. Specifically: ① The payment security level is a security policy obtained by analyzing the social relationships between the target social object and N social objects (excluding the target social object) according to a trust scoring mechanism; each security policy defines the payment method used when paying for the target sub-bill. For example, the payment security level is obtained by analyzing the trust sub-scores between the target social object and each of the N social objects (excluding the target social object) and then weighting the N-1 trust sub-scores. ② Different payment security levels correspond to different payment methods. For example, the higher the payment security level, the simpler the corresponding payment method. A higher security level corresponds to password-free payment, while a lower security level corresponds to password-based payment. Then, the computer device receives the payment operation performed by the target social object on the target sub-bill according to the payment method corresponding to the payment security level, such as the aforementioned password-free or password-based payment operations. Finally, the computer responds to the payment operation by outputting a payment result interface. This interface not only displays the payment result of the target sub-bill (e.g., payment successful or payment failed) but also displays the payment progress information for each social object's assigned sub-bill, such as pending payment, in progress payment, and paid. Therefore, by simplifying the payment verification process based on the social trust relationship between the target social object and the target social object in this bill allocation, under conditions of high social trust, and by dynamically adjusting the verification process, the convenience of the payment verification process is improved, which to some extent helps the target social object achieve rapid payment for the target sub-bill.

[0147] For example, a schematic diagram illustrating how a target social object performs a payment operation on a target sub-bill can be found here. Figure 4The system displays a payment interface 401, which includes security assessment information 402. For example, security assessment information 402 indicates a payment security level of 92 points, corresponding to a password-free payment method. The payment interface 401 also includes at least one payment channel, such as third-party payment or payment through an application with integrated payment processing methods. Thus, when the target social user selects a payment channel, the payment operation for the target sub-bill can be completed using the password-free payment method corresponding to the payment security level. After the payment operation for the target sub-bill is completed, a payment result interface 403 is output. This interface includes the payment result 404 for the target sub-bill and payment progress information for each social user's assigned sub-bill, such as payment progress information 405 and payment progress information 406.

[0148] Furthermore, this application embodiment also supports saving the payment record for the target sub-bill to the billing record after payment is completed, thereby enabling batch management of bills; such as Figure 4 The payment result interface also includes a save component 407. When the target social object selects the save component 407, the payment record for this target sub-bill is directly saved to the bill record. Furthermore, this embodiment of the application supports sharing payment information after payment is completed; this payment information includes, but is not limited to, the payment result of the target sub-bill, the payment results of N social objects for their respective sub-bills, and the sub-bill itself. Figure 4 The payment result interface also includes a sharing component 408. When the sharing component 408 is triggered, the payment information can be shared with any one of the N social objects, or it can be shared with other users other than the N social objects. This application embodiment does not limit this.

[0149] The foregoing mainly introduced the product implementation of the simplified verification process in this application embodiment from the perspective of the interface. The following section introduces the backend implementation logic of the simplified verification process in this application embodiment from the perspective of backend technology. Specifically, a graph neural network is used to analyze the social relationship strength of N social objects; specifically, social network data between the N social objects is obtained, and the graph neural network is called to analyze the social network data to obtain a social trust score for each social object. Then, based on a context-aware dynamic trust assessment mechanism, the social trust score obtained from the social relationship strength analysis is adjusted, and a security policy corresponding to the target social object is applied. Wherein:

[0150] (1) Analyze the strength of social relationships among N social objects based on graph neural networks.

[0151] The relevant content on graph neural networks can be found in the aforementioned descriptions and will not be repeated here. Graph neural network-based social relationship strength analysis and trust scoring can utilize graph neural networks to process social network data between social objects, analyze the strength of social relationships between them, and calculate social trust scores, providing a foundation for subsequent identity recognition, consumption allocation, and verification simplification.

[0152] The process for analyzing the social relationship strength of N social objects based on a graph neural network model can be found in [link to documentation]. Figure 5 It mainly includes a data collection layer, a graph construction layer, a feature extraction layer, a graph neural network layer, and a relationship scoring layer. Among them:

[0153] ① The data collection layer is mainly used to collect social relationship data, which includes, but is not limited to: social interaction data between social objects, payment history data of each social object, group activity data of payment groups composed of N social objects, and location co-occurrence data of each social object (such as GPS positioning), etc.

[0154] ② The graph construction layer supports treating each social object as a node. Based on the social relationship data collected by the data collection layer, edges are set between social objects with social relationships, and attribute values ​​are assigned to nodes and / or edges. For example, the attribute values ​​assigned to nodes include data such as the gender, age, and consumption preferences of the social object, while the attribute values ​​assigned to edges include the type of social relationship between social objects (such as friend relationship, stranger relationship) and the strength of the social relationship (such as frequent interaction, only one interaction, etc.). After constructing the initial graph structure based on nodes, edges, and attribute values, the initial graph structure is evolved into a time sequence graph to obtain the final graph structure or graph structure data. That is, the initial graph structure is improved and updated so as to clearly show the interaction process and time sequence relationship between social objects.

[0155] ③ The feature extraction layer is used to extract features from the graph structure constructed by the graph construction layer, so as to extract feature data for subsequent trust assessment calculations. Feature extraction includes: node feature extraction, edge feature extraction, path feature extraction, and group feature extraction. Node feature extraction mainly extracts features from each node to analyze the object characteristics of each social object, such as consumption preference characteristics and identity characteristics. Edge feature extraction mainly extracts features from each edge to analyze the relationship characteristics between social objects, such as relationship strength and relationship type. Path feature extraction is mainly used to extract path features from the graph structure to analyze the social relationships between multiple social objects. Group feature extraction is used to extract overall features from the graph structure to analyze the group characteristics of a payment group composed of N social objects, such as consumption scenario characteristics, consumption time characteristics, and consumption location and time.

[0156] ④ The graph neural network layer mainly processes the feature data extracted by the feature extraction layer through graph convolutional networks, attention mechanisms, message passing mechanisms, and temporal learning mechanisms to obtain processed feature information. Among them, graph convolutional networks are a special convolution operation based on graph-received data, which fully considers the structural characteristics of the graph during the convolution operation; attention mechanisms can focus on important parts of the input feature data to obtain more accurate and richer semantic information; message passing mechanisms are mainly used for message passing between different computing threads in the trust scoring evaluation process; and temporal learning mechanisms can process temporal data of arbitrary length and retain the influence of long-term history during the processing, thereby achieving accurate modeling and prediction of temporal data.

[0157] ⑤ The relationship scoring layer is used to calculate the social relationship strength of each social object based on the feature information transmitted by the graph neural layer, generate a social trust score for each social object, identify the social relationship type between social objects, and update the graph neural network model.

[0158] (2) Context-aware dynamic trust assessment mechanism.

[0159] Context awareness is the application's ability to perceive and understand the current consumption scenario, including factors such as consumption location, consumption time, social relationships between social objects, and consumption type. A context-aware dynamic trust assessment mechanism can adjust social trust scores in real time based on the specific consumption scenario, the resource limit of the bill, and the behavior of social objects. Combined with the anomaly detection capabilities of the corresponding intelligent agents, it provides more accurate security guarantees.

[0160] For ease of explanation, taking a target social object out of N social objects as an example, this paper introduces the technical implementation process of adjusting the social trust score of the target social object based on a context-aware dynamic trust assessment mechanism to determine the security strategy for the target social object; this technical implementation process can be found in [reference needed]. Figure 6After N social objects confirm their assigned sub-bills, any social object—the target social object—initiates a payment request for the target sub-bill to the application. The application then requests a risk assessment from the backend server (specifically, the agent corresponding to the target social object). The agent for the target social object analyzes multi-dimensional trust factors, including but not limited to: assessing the strength of the social relationship, analyzing historical transaction records, and assessing the characteristics of the consumption scenario. It dynamically adjusts the weights of each trust factor to obtain a new social trust score after adjusting the social trust assessment. The agent also calculates a contextual trust score, including but not limited to: detecting behavioral anomalies (i.e., whether the target social object's payment behavior is abnormal), analyzing operational patterns (such as the pattern of the target social object's operations), and assessing contextual consistency. Based on the contextual trust score and the new social trust score, the agent determines the payment risk level. The agent selects a corresponding security policy based on the payment risk level and returns the security policy to the application. The application displays a payment interface based on the security level, which includes security assessment information representing the payment security level of the target social object. Assume payment security levels are divided into high-risk, medium-risk, and low-risk transactions. For medium-risk transactions, the target social object needs to complete the payment according to a standard verification process, such as entering a password. For high-risk transactions, the target social object needs to complete the payment according to a multi-factor authentication process. Usually, additional authentication methods are added to the standard verification process to improve payment security. For low-risk transactions, the verification process can be simplified to help the target social object complete the payment quickly.

[0161] In summary, on the one hand, in multi-person consumption scenarios, the system intelligently splits the bill to be paid directly, eliminating the need for a single payment bill. This improves the intelligence of bill splitting, and the resulting N sub-bills are directly shared among the N social contacts in the multi-person consumption scenario. This allows each social contact to view their own and others' sub-bills, achieving openness and transparency in bill allocation. On the other hand, adding a confirmation step for each social contact regarding the sub-bills during the bill allocation process enhances the interactivity among social contacts in multi-person consumption scenarios. This interactivity provides social contacts with an entry point to submit objections to sub-bills, thereby significantly improving the fairness of bill allocation.

[0162] Based on the foregoing Figure 1a As shown in the schematic diagram, this embodiment supports N social entities as participants in collaborative payment, simultaneously receiving N sub-bills from the backend and simultaneously confirming and paying for the sub-bills. In this case, the service interface displayed on the terminal side of each social entity and the collaborative payment process are the same, as described above. Figure 2 The description of the illustrated embodiments is based on the foregoing. Figure 1bAs shown in the schematic diagram, this application embodiment also supports one social object among N social objects as the initiator of collaborative payment, and other device objects among the N social objects as participants in collaborative payment. In this case, the service interface displayed on the terminal side held by the initiator and the participants and the collaborative payment process are not exactly the same. The main difference is in the confirmation process of the sub-bill, but the payment process for the sub-bill is the same, and the service interface displayed on the terminal side held by each participant and the collaborative payment process are the same.

[0163] For ease of explanation, the following sections will describe the implementation methods of the payment processing scheme provided in this application when there are initiators and participants, specifically the first social object among N social objects that initiates collaborative payment for a bill, and the second social object among N social objects that participates in the collaborative payment for a bill. Please refer to... Figure 7 , Figure 7 The diagram illustrates a flowchart of another payment processing method provided in an exemplary embodiment of this application. Figure 7 The payment processing method shown can be executed by a computer device. Taking the computer device as an example, which is a terminal held by the first social object initiating a collaborative payment for a bill, the payment processing method includes, but is not limited to, steps S701-S705:

[0164] S701: Displays the bill interface in response to a bill viewing operation.

[0165] The bill viewing operation refers to the operation of the first social object obtaining the bill to be paid and viewing the details of the bill. In this embodiment, the bill receiving operation may include, but is not limited to: scanning the QR code provided by the merchant, sensing the payment QR code device provided by the merchant, order submission in the shopping application, triggering the bill receiving message in the application, and editing the bill on the bill creation interface performed by the first social object, etc. In other words, the bill to be paid collaboratively may be directly issued to the first social object by the merchant, or it may be actively created by the first social object according to the consumption items in the consumption scenario.

[0166] In specific implementation, the terminal held by the first social object responds to the bill viewing operation performed by the first social object, and can display the bill interface, which includes bill details and a collaborative payment entry. Taking the bill viewing operation as a trigger operation for receiving bill messages in the application as an example, a diagram illustrating the display of the bill interface based on the bill viewing operation can be found here. Figure 8 ;like Figure 8As shown, the first social user receives a bill receipt message 801 from the merchant via scanning a QR code, device sensing, or other means. This bill receipt message 801 indicates that the first social user needs to pay the bill. When the first social user triggers an operation on the bill receipt message 801, the bill interface 802 is displayed. The bill interface 802 includes bill information, such as the bill's resource limit, merchant name, and consumption time. The bill interface 802 also includes a collaborative payment entry point 803, which is used to access the collaborative payment function.

[0167] S702: In response to a triggered operation targeting the collaborative payment entry point, display the collaborative payment interface.

[0168] In the specific implementation, the computer device responds to the first social object's trigger operation on the collaborative payment entry in the bill interface, displaying the collaborative payment interface. This collaborative payment interface includes an object addition area, which can be understood as an area for selecting social objects to participate in this bill sharing. Then, the first social object can perform an object addition operation in this object addition area. In response to this object addition operation, the computer device will display the object identifier of each of the N social objects selected to participate in the bill sharing in real time in the object addition area.

[0169] The object addition operation is performed by the first social object, enabling users to invite a second social object to participate in bill sharing. For example, the object addition operation may include at least one of the following:

[0170] ① A selection operation performed on object identifiers from an object list. The object list is a list of object identifiers from multiple social objects that have established social relationships with the first social object. For example, the object list could be the first social object's friend list in a social application. In this case, an object selection component can be set in the object addition area. When this component is triggered, the first social object's object list is displayed, allowing the first social object to select all or some of the second social objects participating in this bill sharing from the object list. Figure 9a As shown, in response to the triggering operation of the collaborative payment entry in the statement interface, the collaborative payment interface 901 is displayed. The collaborative payment interface 901 includes an object addition area 902, which includes an object selection component 903. When the object selection component 903 is triggered, an object list 904 is output. The object list 904 includes one or more candidate object identifiers. When any object identifier is selected, the social object corresponding to that object identifier becomes the second social object participating in this bill sharing.

[0171] ② The operation of selecting recommended social objects. Here, the recommended social object is the social object selected by the application for the first recommended social object in this billing scenario; this recommended social object may be recommended by the application based on the historical transaction records of the first social object, or determined based on the location of friends within the same geographical area as the first social object, etc. This application embodiment does not limit the specific implementation method of the application determining the recommended social object. For example... Figure 9b As shown, the recommended social objects recommended by the application for the first social object can be displayed in the object addition area 902 when the collaborative payment interface is triggered, such as the object identifier 905 of recommended social object 1 and the object identifier 906 of recommended social object 2; in this way, the first social object can directly perform a selection operation on the object identifier of the recommended social object in the object addition area 902, and the recommended social object corresponding to the selected object identifier will be used as the second social object to participate in this bill sharing.

[0172] ③ Joining the payment group of the first social contact by sharing an invitation message. The invitation message can be an invitation code, such as 1234; the payment group of the first social contact refers to a group formed by N social contacts participating in the bill sharing. For example... Figure 9c As shown, this application embodiment supports displaying invitation information 907 in the object addition area 902 of the collaborative payment interface when the collaborative payment interface is triggered through the collaborative payment entry. The first social object can share the invitation information 907 with the social object that wants to team up to share the bill through offline or online means. The social object that receives the invitation information can join the payment group in the application by clicking or entering the invitation information 907 and share the bill with the first social object.

[0173] ④ Input operation for the object identifier of the social object. That is, this application embodiment supports the first social object directly selecting a specified social object as the second social object for this bill allocation by inputting the object identifier. For example... Figure 9d As shown, the object addition area 902 includes an information input area 908. The first social object can input an object identifier in the input area 908. The social object corresponding to the object identifier is a social object that has registered an application with the first social object. In this way, the social object corresponding to the input object identifier becomes the second social object for this bill allocation.

[0174] It should be noted that, Figure 9a , Figure 9b , Figure 9c and Figure 9dThese are illustrative diagrams illustrating various exemplary groupings of N social objects provided in this application's embodiments, and do not limit the scope of this application's embodiments. By providing diverse object selection methods for the first social object, this application's embodiments can fully meet the needs of forming payment groups in various consumption scenarios; for example, if multiple social objects participating in a consumption scenario are in the same physical space, collaborative payment can be quickly achieved through invitation information; furthermore, if the distance between multiple social objects participating in a consumption scenario is far, the selection of a second social object can be quickly achieved through a friend list.

[0175] S703: Display the sub-bills assigned to each social object based on the bill allocation operation performed in the collaborative payment interface.

[0176] As mentioned above, this application embodiment mainly uses the allocation rules defined by the bill allocation strategy to distribute bills among N social objects. The bill allocation strategy can include any of the following: a recommended allocation strategy, a set allocation strategy, and a reference allocation strategy. The recommended allocation strategy is an allocation strategy generated by the application based on the consumption information of the social objects. This recommended allocation strategy is used to define the allocation rules for distributing bills among N social objects according to their consumption information. Specifically: ① The recommended allocation strategy can further include a first sub-recommendation allocation strategy and a second sub-recommendation allocation strategy. The first sub-recommendation recommendation strategy is used to define the allocation rules for distributing bills among N social objects according to the consumption information of the first social object; that is, the first sub-recommendation allocation strategy focuses on distributing bills according to the consumption habits of the first social object, thus the way the bill is split according to the first sub-recommendation allocation strategy is more in line with the initiator's preference. The second sub-allocation recommendation strategy defines the allocation rules for distributing bills among N social objects based on their historical collaborative payment information. In other words, the second sub-allocation strategy focuses on allocating bills according to the historical collaborative payment habits of the N social objects, ensuring that sub-bills allocated based on historical collaborative consumption habits are more likely to align with the consumption habits of most social objects. ② The setting allocation strategy is a custom allocation rule defined by the first social object, meeting the need for manual configuration of the allocation strategy in specific scenarios. ③ The reference allocation strategy is a bill allocation rule automatically reached through negotiation and game theory among the N agents corresponding to the N social objects in the background; optionally, the generation process of this reference allocation strategy may refer to the recommended allocation strategy and / or the setting allocation strategy.

[0177] The following describes the process of displaying the N sub-bills after the bill is split according to the bill allocation strategy on the first social object side; where:

[0178] I. The bill allocation strategy is the recommended allocation strategy.

[0179] In the specific implementation, a recommended allocation strategy is displayed on the collaborative payment interface. This strategy is generated by the agent corresponding to the first social object based on the consumption information of the first social object or N social objects. If the first social object wants to split the bill using the recommended allocation strategy, it selects that strategy. Correspondingly, the backend splits the bill according to the strategy and pushes the resulting N sub-bills to the first social object's terminal for display. At this point, the N sub-bills are allocated based on the allocation strategy defined in the recommended allocation strategy. This method of directly using the recommended allocation strategy generated by the agent corresponding to the first social object, compared to equal distribution or manually setting the allocation amount, not only improves the intelligence and rationality of bill splitting when the associated consumption items are relatively simple, but also enhances the speed of collaborative payment. Furthermore, since the recommended allocation strategy is generated based on the message information of the first social object or N social objects, it can, to a certain extent, ensure that the sub-bills split based on the recommended allocation strategy conform to the preferences of the social objects.

[0180] For example, a diagram illustrating the selection of a recommended allocation strategy for bill splitting can be found here. Figure 10a ;like Figure 10a The collaborative payment interface shown displays a floating window 1001 associated with the agent corresponding to the first social object. This floating window 1001 includes a recommended allocation strategy 1002 and a confirmation component 1003. Specifically, the recommended allocation strategy 1002 can be either the aforementioned first sub-recommendation allocation strategy or the second sub-recommendation allocation strategy. When the first social object wants to use the recommended allocation strategy for bill sharing, it can perform a selection operation on the confirmation component 1003. At this time, the collaborative payment interface displays N sub-bills obtained by splitting the bill based on the allocation rules defined by the recommended allocation strategy, such as sub-bills 1004 assigned to the first social object, sub-bills 1005 assigned to the second social object 1, and sub-bills 1006 assigned to the second social object 2.

[0181] The foregoing primarily described the schematic diagram of displaying the recommended allocation strategy in the collaborative payment interface from an interface perspective. The following section describes the reinforcement learning process for the agent corresponding to the social object from a backend technical perspective, specifically using the agent corresponding to the first social object as an example. For details on the reinforcement learning process for the agent, please refer to [link to relevant documentation]. Figure 10b .like Figure 10bAs shown, each social object's corresponding intelligent agent acts as its payment assistant, learning the social object's payment habits, social preferences, and consumption patterns, and proactively providing allocation suggestions to optimize the multi-person collaborative payment experience. The intelligent agent mainly includes the following modules: a user model module, a context-aware module, a decision engine module, and an interaction interface module. Specifically: the user model module captures the social object's payment habits, consumption preferences, and social behavior; the context-aware module primarily identifies the current consumption scenario and social environment patterns; the decision engine module, also known as the Consumption Distribution Engine, analyzes the correlation between consumption items and social objects, generating personalized bill allocation schemes; and the interaction interface module prepares data for the service interface rendering.

[0182] In practical applications, embodiments of this application support continuously optimizing the agent's decision-making capabilities by observing the payment decisions and feedback of social objects and utilizing reinforcement learning. Specifically, this may include using multi-objective reinforcement learning algorithms to balance social experience, social harmony, and economic benefits, and employing federated learning technology to achieve knowledge sharing across social objects while protecting their privacy. Figure 10bAs shown, the process of reinforcement learning for an intelligent agent to achieve continuous optimization of decision-making capabilities can roughly include: the agent receives a bill-sharing negotiation request initiated by a social object (e.g., the first social object); the agent sends the social object's consumption information (e.g., consumption preferences) to a user model; the user model analyzes the social object's payment habits, consumption preferences, and social behavior patterns based on the consumption information, and returns user model data to the agent. The agent also sends a consumption scenario recognition request to a context-aware module; the context-aware module analyzes the social object's location information, time characteristics, social environment, and consumption type, and returns context data to the agent. The agent generates a strategy request based on the user model data and context data, and sends the strategy request to the decision engine module. This strategy request requests the decision engine module to generate a bill allocation strategy based on the user model data and context data. Correspondingly, the decision engine module comprehensively analyzes the user model data and context data to generate one or more candidate allocation strategies, and evaluates each candidate strategy, aiming to select the optimal allocation strategy from the one or more candidate strategies. This optimal allocation strategy may be one or more candidate allocation strategies that better match the social object's consumption preferences and habits. Then, the decision engine module returns the optimal allocation strategy to the agent, enabling the agent to generate natural language descriptions and visually appealing allocation suggestions based on the optimal strategy through the interactive interface module. This allocation suggestion information is then output to the social objects for viewing. The interactive interface module can receive feedback from the social objects regarding the allocation suggestions and transmit this feedback to the agent. Based on this feedback and the allocation suggestions, the agent optimizes its parameters, specifically adjusting the parameters of each module within the agent to achieve overall performance optimization.

[0183] II. Bill allocation strategy: Set the allocation strategy.

[0184] In specific implementation, the collaborative payment interface includes a strategy configuration option, which serves as the entry point for manually creating and setting allocation strategies. The first social object triggers the strategy configuration option in the collaborative payment interface, and the computer device detects this trigger and displays the strategy configuration interface. This interface is used to configure the allocation strategy. The computer device receives the strategy configuration operation performed by the first social object in the strategy configuration interface and displays the sub-bills assigned to each social object. At this point, N sub-bills are obtained by allocating bills based on the allocation strategy generated by the strategy configuration operation performed by the first social object. Therefore, this embodiment supports the first social object in customizing the allocation strategy, meeting the needs of social objects in complex consumption scenarios and providing rich strategy creation methods for social objects.

[0185] For example, a diagram illustrating the bill splitting process using a custom allocation strategy for the first social object can be found here. Figure 11 ;like Figure 11 The collaborative payment interface shown displays a floating window associated with the agent corresponding to the first social object. This floating window includes a strategy configuration option 1101. When strategy configuration option 1101 is triggered by the first social object, a strategy configuration interface 1102 is displayed. This interface includes at least one strategy configuration item, with each item corresponding to a consumption item. For example, strategy configuration item 11021 corresponds to a staple food item in a dining scenario, strategy configuration item 11022 corresponds to a seafood item, and strategy configuration item 11023 corresponds to a beverage item. The first social object can configure each strategy configuration item by performing strategy configuration operations, such as selection or input. After each strategy configuration item is configured, the first social object can perform a selection operation on the submission option 1103 in the strategy configuration interface 1102. At this time, the information configured for each strategy configuration item in the interface 1102 is used as the source for creating and setting the allocation strategy. Furthermore, the user returns from the strategy configuration interface to the collaborative payment interface, where N sub-bills are displayed, obtained by splitting the bill according to the set allocation strategy.

[0186] It is worth noting that, to facilitate the verification of the configuration allocation strategy for the first social object, this application embodiment also supports real-time display of sub-bills obtained by splitting the bill according to the configuration information in the strategy configuration interface. For example... Figure 11 The strategy configuration interface shown includes sub-bills 1104, 1105, and 1106, and each sub-bill includes the source components of the resource quota, which greatly improves the convenience of setting allocation strategies for the first social object verification.

[0187] III. The bill allocation strategy is a reference allocation strategy.

[0188] As mentioned above, each of the N social objects participating in collaborative payment corresponds to an intelligent agent, which is used to negotiate bill allocation on behalf of the social object; the reference allocation strategy is created by the N intelligent agents in the background to negotiate the bill.

[0189] In specific implementation, the collaborative payment interface also includes an allocation negotiation area, which is a visual representation of the bill allocation negotiation process among N intelligent agents. This application embodiment supports displaying allocation suggestion information sent by each intelligent agent in the form of conversational messages within the allocation negotiation area; that is, the bill allocation negotiation process among N intelligent agents can be understood as a conversation among N intelligent agents in a payment group. The target allocation suggestion information sent by the intelligent agent corresponding to the first social object among the N intelligent agents can be the aforementioned recommended allocation strategy and / or set allocation strategy, or it can be other allocation strategies created by the intelligent agent corresponding to the first social object based on other dimensions, different from the recommended allocation strategy and set allocation strategy; this application embodiment does not limit this. The allocation suggestion information sent by the intelligent agent corresponding to any second device object among the N social objects (excluding the first social object) is generated from multiple evaluation dimensions, including but not limited to fairness and consumption habit dimensions, so as to refute or raise objections to the target allocation suggestion information sent by the intelligent agent corresponding to the first social object through this allocation suggestion information. Furthermore, when the bill allocation negotiation among N agents in the allocation negotiation area ends, the N sub-bills obtained by allocating the bill based on the reference allocation strategy can be displayed in the collaborative payment interface; the reference allocation strategy is generated based on the allocation suggestion information sent by the N agents.

[0190] Therefore, the embodiments of this application construct a multi-agent collaborative network, enabling the agents corresponding to each social object participating in collaborative payment to negotiate and compete in the background, thereby achieving group decision optimization based on multi-agent collaboration. This not only automatically achieves a better reference allocation strategy, but also ensures that the sub-bills split according to the reference allocation strategy can meet the consumption habits and preferences of each social object, thus achieving the intelligence and interactivity of collaborative payment.

[0191] For example, a diagram illustrating bill splitting using a reference allocation strategy can be found here. Figure 12 ;like Figure 12 The collaborative payment interface shown displays a floating window associated with the agent corresponding to the first social object. This floating window includes negotiation option 1201, which can be... Figure 10aThe confirmation component shown can also be a separate component independent of the confirmation component. When the negotiation option 1201 is triggered, the allocation negotiation area 1202 in the collaborative payment interface is displayed. In the allocation negotiation area 1202, allocation suggestion information sent by each agent is displayed in the form of session messages, such as the target allocation suggestion information 12021 sent by the agent corresponding to the first social object, and the allocation suggestion information 12022 sent by the agent corresponding to the second social object 1. Considering that the display area of ​​the allocation negotiation area 1202 is limited, this embodiment also supports sliding to reveal hidden allocation suggestion information in the allocation negotiation area 1202, so that the first social object can fully view the allocation suggestion information sent by all agents. When the bill allocation negotiation in the allocation negotiation area ends, N sub-bills obtained by splitting the bill based on the reference allocation strategy obtained through negotiation among N agents are displayed in the collaborative payment interface.

[0192] Furthermore, if the first social object disagrees with the reference allocation strategy negotiated by the N agents, this embodiment also supports the first social object to fine-tune or optimize the reference allocation, aiming to improve the rationality of the reference allocation strategy. Specifically, the collaborative payment interface also includes an adjustment component. In response to the first social object's trigger operation on the adjustment component, the computer device can display a strategy configuration interface. As mentioned earlier, the strategy configuration interface includes at least one strategy configuration item, each corresponding to a consumption item, and the strategy configuration item displays the corresponding configuration information in the reference allocation strategy. Then, the first social object can perform an adjustment operation on the strategy configuration item. Based on the first social object's adjustment operation on the strategy configuration item in the strategy configuration interface, the computer device displays N first fine-tuned sub-bills obtained by allocating the bill based on the adjusted reference allocation strategy. In this case, when the target social object subsequently performs a confirmation operation on the target sub-bill, it specifically receives the target social object's confirmation operation on the target sub-bill among the N first fine-tuned sub-bills.

[0193] For example, a schematic diagram illustrating the fine-tuning of the reference allocation strategy can be found in [reference needed]. Figure 13 ;like Figure 13As shown, the collaborative payment interface includes an adjustment component 1301. When the adjustment component 1301 is triggered, it indicates that the first social object wants to fine-tune the reference allocation strategy negotiated by N agents. The user then returns to the strategy configuration interface from the collaborative payment interface. Each strategy configuration item in this interface displays the corresponding configuration information of the reference allocation strategy by default. For example, strategy configuration item 1302 – Staple Foods displays the configuration information related to the "staple food" consumption item in the reference allocation strategy, and strategy configuration item 1303 – Seafood displays the configuration information related to the "seafood" consumption item in the reference allocation strategy. In this case, the first social object can adjust only the configuration information of the strategy configuration item that needs fine-tuning according to its own adjustment needs, such as adjusting the allocation method displayed in strategy configuration item 1302. Thus, when a confirmation operation is performed on the fine-tuned reference allocation strategy in the strategy configuration interface, the user returns to the collaborative payment interface, which displays N first fine-tuned sub-bills obtained by allocating the bill based on the adjusted reference allocation strategy. Of course, to facilitate the second confirmation of the adjusted reference allocation strategy by the first social object, this application embodiment supports real-time preview and display of the sub-bills obtained by splitting the bill based on the adjusted reference allocation strategy in the strategy configuration interface, and only after confirming the previewed sub-bills will the collaborative payment interface be displayed, and the N first fine-tuned sub-bills obtained by allocating the bill based on the adjusted reference allocation strategy will be displayed in the collaborative payment interface.

[0194] The foregoing mainly describes the visual negotiation process between multiple intelligent agents from the interface dimension. The following describes the negotiation process of N intelligent agents in the background from the background technology dimension. As mentioned above, the first social object is the initiator of the entire collaborative payment process. This application embodiment supports the intelligent agent corresponding to the first social object as a device to realize information aggregation and integration in the multi-intelligent agent negotiation process. In this case, the specific implementation of the intelligent agent corresponding to the first social object to realize the aggregation of allocation suggestion information and the generation of reference allocation strategy in the negotiation process may include: (1) obtaining target allocation suggestion information, which is generated by the intelligent agent corresponding to the first social object, and receiving allocation suggestion information sent by the intelligent agents corresponding to N-1 second social objects for the target allocation suggestion information. As mentioned above, the target allocation suggestion information may be a recommended allocation strategy generated by the intelligent agent corresponding to the first social object, or it may be a custom allocation strategy set by the first social object. When the target allocation suggestion information is a recommended allocation strategy, the generation process of the recommended allocation strategy may include: ① obtaining the consumption information of each second social object, such as obtaining the consumption preferences of each second social object. ② predicting the association information between each social object and the bill based on the message information of each social object in the N social objects. Specifically, this involves analyzing the consumption scenario of the bill to obtain scenario analysis results. Based on these results, the social relationship information between N social objects and their behavioral patterns, the identity information of each social object in the consumption scenario is identified, such as the first social object being the initiator and the second social object being a participant. Next, at least one consumption item associated with the bill is obtained. Based on the identity information and message information corresponding to each social object, as well as the item characteristics of each consumption item, association information between each social object and each consumption item is established. Any association information includes matching information between the social object and the consumption item. For example, if the matching information falls within the range [0,10], the matching information between social object 1 and consumption item 1 is 3, and the matching information between social object 1 and consumption item 2 is 5. ③ The target allocation pattern is obtained, and a recommended allocation strategy is generated based on the association information and the target allocation pattern. The target allocation pattern is any one of one or more allocation patterns, including but not limited to: average allocation, proportional allocation, role allocation, and custom allocation. (2) Based on the allocation suggestion information and the target allocation suggestion information, the strategy integration process is performed to generate a reference allocation strategy. It can be seen that the generation of the reference allocation strategy is generated by negotiating the allocation suggestion information proposed by the agents corresponding to N social objects.

[0195] The technical implementation framework for the identity recognition and reference allocation strategy described above can be found in [reference needed]. Figure 14 ;like Figure 14As shown, the system mainly includes a scenario analysis module, an identity recognition module, a consumption association module, and an intelligent allocation module. The scenario analysis module is primarily used for: identifying the scenario type of the consumption scenario, estimating the number of users participating in the bill allocation, analyzing the spatial location of each social object, and analyzing the consumption time. The identity recognition module is primarily used for: facial recognition matching to match the identities of N social objects; device signal matching to match social objects with their respective terminals; social relationship matching to analyze the social relationship network among N social objects; and behavioral pattern matching to match the operational behaviors performed by social objects with the consumption scenario. The consumption association module is primarily used for: consumption item classification to classify at least one consumption item associated with the bill; consumption preference matching to analyze the matching between the consumption preferences of social objects and consumption items; historical consumption analysis to analyze the historical consumption habits of social objects; and item-object association to calculate the correlation between social objects and each consumption item. The intelligent allocation module is primarily used to construct a reference allocation strategy based on one or more allocation modes, combined with the association information between each social object and each consumption item output by the consumption association module.

[0196] Based on the above description of the multi-agent negotiation process for the agent corresponding to the first social object, to better understand how bill sharing negotiation is achieved among multiple agents, the following example uses the first social object and a second social object, combined with... Figure 15 This section introduces the multi-agent collaboration framework and the interaction process between multiple agents. For example... Figure 15As shown, after detecting a multi-person consumption scenario, the agent corresponding to the first social object sends a negotiation request to the agent corresponding to the second social object. The agent corresponding to the second social object analyzes the consumption information of the second social object and uses a utility function to analyze the consumption preferences of the second social object, and then sends the consumption preferences and other information of the second social object to the agent corresponding to the first social object. The agent corresponding to the first social object uses a pre-built game theory model based on the consumption preferences of the second and first social objects, and applies techniques such as Nash equilibrium and Pareto improvement to solve for the optimal objective allocation suggestion information. Here, a game theory model is a mathematical or logical framework for describing and analyzing game situations, used to predict and explain how social objects make decisions under specific rules and conditions and how these decisions affect the final outcome; Nash equilibrium is an important concept in game theory, used to ensure that each social object chooses the strategy most beneficial to itself while considering the strategy choices of other social objects; Pareto optimality is an optimization concept that emphasizes keeping the strategies of other social objects unchanged when it is impossible to improve one social object, and is a global equilibrium concept. Then, the agent corresponding to the first social object sends the target allocation suggestion information to the agent corresponding to the second social object. The agent corresponding to the second social object evaluates the target allocation suggestion information from multiple dimensions (such as fairness and consumption preference) and returns the evaluated allocation suggestion information to the agent corresponding to the first social object. The agent corresponding to the first social object integrates the allocation suggestion information from the first and second social objects and optimizes and generates a reference allocation strategy. The agent corresponding to the first social object also sends the reference allocation strategy to the agent corresponding to the second social object for confirmation; if the agent corresponding to the second social object does not confirm the reference allocation strategy, the two agents negotiate until the agent corresponding to the second social object confirms the reference allocation strategy. Once the agent corresponding to the second social object confirms the reference allocation strategy, the agent corresponding to the first social object shares the N bills allocated according to the reference allocation strategy to the first social object (shared to the second social object only after confirmation by the first social object), or shares them to both the first and second social objects simultaneously, so that the social objects participating in the bill sharing can see the result of the negotiation between the agents.

[0197] S704: Receive confirmation from the target social object for the corresponding target sub-bill.

[0198] The target social object is the first social object. When the first social object performs a confirmation operation on the N sub-bills displayed in the collaborative payment interface, which are split according to the reference allocation strategy, it means that the first social object agrees to the bill allocation method, that is, confirms the target sub-bills assigned to it. Then, the agent corresponding to the first social object sends the N sub-bills to N-1 second social objects, so that the second social objects can confirm or raise objections to the N sub-bills.

[0199] A diagram illustrating the first social interaction's confirmation process for N sub-bills can be found here. Figure 16 ;like Figure 16 As shown, a collaborative payment interface is displayed on the terminal screen held by the first social object. This interface displays the sub-bills assigned to each social object and includes a confirmation option 1601. When confirmation option 1601 is triggered, it indicates that the first social object has confirmed N sub-bills. The agent corresponding to the first social object then sends the N sub-bills to N-1 second social objects and displays a confirmation waiting interface 1602. This interface displays the confirmation progress information for each social object regarding its assigned sub-bills. The confirmation progress information can include: confirmed, awaiting confirmation, and unconfirmed; for example, the first social object's confirmation progress information 1603 indicates confirmed. By displaying the confirmation progress information for each social object in the confirmation waiting interface, the first social object can promptly understand the confirmation progress of the second social objects, alleviating its anxiety during the wait.

[0200] Furthermore, to improve the speed of collaborative payments among N social users and alleviate the waiting anxiety of the first social user, this application embodiment supports the first social user urging a second social user who has not yet confirmed or raised objections, so that the second social user can provide feedback on the N sub-bills as soon as possible, significantly improving the interactivity between social users in multi-person consumption scenarios. Specifically, when the confirmation progress information of the second social user for the assigned sub-bills is "waiting for confirmation" or "not confirmed," and the confirmation progress duration exceeds a time threshold (e.g., 1 minute), a confirmation reply window is displayed on the confirmation waiting interface. This confirmation reply window includes confirmation reply information, which represents the predicted feedback time of the second social user for the sub-bills, such as a predicted feedback time of 30 seconds. The confirmation reply window also includes a confirmation prompt option; the first social user can execute a trigger operation for this confirmation prompt option. In response to this trigger operation, a prompt message is sent to the second social user (specifically, to the terminal held by the second social user). The prompt message prompts the second social user to provide feedback on the assigned sub-bills, such as performing bill confirmation or modifying policy settings.

[0201] For example, a schematic diagram of the confirmation reply window can be found here. Figure 17 ;like Figure 17 As shown, when the display duration of the confirmation waiting interface exceeds a time threshold and the second social object has not yet responded, a confirmation reply window 1701 is displayed on the confirmation waiting interface. This confirmation reply window 1701 describes confirmation reply information representing the predicted response time of the second social object regarding the sub-bill. The confirmation reply window 1701 also includes a confirmation prompt option 1702. When the confirmation prompt option 1702 is triggered, a prompt message is sent to the second social object, prompting them to respond as soon as possible. It is worth noting that, in addition to the conditions described above, the display of the confirmation reply window 1701 can also be initiated by the first social object from the confirmation waiting interface. This embodiment of the application does not limit the display conditions of the confirmation reply window.

[0202] Furthermore, after receiving N sub-bills, the second social object will provide feedback on them. This feedback includes confirming the sub-bills assigned to it, or, if it disagrees with the sub-bills assigned to it, setting policy modification information to be fed back to the first social object for adjustment of the reference allocation policy. When the second social object disagrees with the sub-bills assigned to it and edits the policy modification information, this information is sent to the corresponding agent of the first social object. In specific implementation, if policy modification information related to the second social object is displayed on the confirmation waiting interface of the first social object, it indicates that the second social object has raised an objection to the current bill allocation policy. In response to the first social object's acceptance of the policy modification information, the policy configuration interface is displayed. As mentioned above, the policy configuration interface includes at least one policy configuration item. Each policy configuration item displays the corresponding configuration information in the reference allocation policy, and the target policy configuration item related to the policy modification information is highlighted (e.g., highlighted, darkened background color) in the policy configuration interface so that the first social object can intuitively perceive which consumption item the second social object has objected to. In response to a policy fine-tuning operation by the first social object regarding the target policy configuration item, such as adjusting the configuration information of the target policy configuration item to the suggested information provided by the second social object, or modifying the configuration information of the target policy configuration item to information related to the suggested information provided by the second social object, N second fine-tuned sub-bills are displayed, resulting from the fine-tuning allocation strategy generated based on the policy fine-tuning operation. This fine-tuning allocation strategy is a bill allocation strategy adjusted according to the policy modification information based on the reference allocation strategy. When the first social object performs a confirmation operation on the N second fine-tuned sub-bills, the N second fine-tuned sub-bills are sent to N-1 second social objects, and a confirmation waiting interface is displayed. The process restarts, waiting for feedback from the N-1 second social objects on their respective assigned second fine-tuned sub-bills (this feedback also includes confirmation or provision of policy modification information).

[0203] Therefore, the embodiments of this application support providing a way for N social objects to raise objections to the reference allocation strategy, realizing the interactivity of social objects in the bill sharing in multi-person consumption scenarios, significantly improving the rationality of bill sharing, and to a certain extent increasing the fun of bill sharing in multi-person consumption scenarios.

[0204] For example, a schematic diagram illustrating how the first social object receives policy modification information sent by the second social object and performs fine-tuning of the reference allocation policy can be found in [reference needed]. Figure 18 ;like Figure 18As shown, after the first social object confirms the target sub-bill, N sub-bills are sent to N-1 second social objects for confirmation. If the second social objects have objections to the N sub-bills, a prompt window 1802 is displayed on the collaborative payment interface, which includes policy modification information. To facilitate the first social object's awareness of this policy modification information, a jump option 1801 is displayed in the confirmation reply window of the collaborative payment interface. The first social object can click on this jump option 1801 to quickly display the prompt window 1802. Then, if the first social object decides to accept the policy modification information and adjust the reference allocation policy, in response to the triggering operation of the receiving component 1803 in the prompt window 1802, the policy configuration interface is displayed, and the target policy configuration item 1804 related to the policy modification information is highlighted in the policy configuration interface so that the first social object can quickly perceive the location of the target policy configuration item 1804 to be modified. After the first social object completes the modification of the reference allocation strategy, the confirmation option 1805 can be triggered to send N second fine-tuning sub-bills to N-1 second social objects for a second round of confirmation.

[0205] S705: After N social objects have performed confirmation operations on their respective assigned sub-bills, receive the payment operation performed by the target social object on the target sub-bill.

[0206] It should be noted that the specific implementation process shown in step S705 is the same as that described above. Figure 2 The specific implementation process shown in step S203 in the illustrated embodiment is the same. Please refer to the relevant description of the specific implementation process shown in step S203, which will not be repeated here.

[0207] In summary, the embodiments of this application support the use of N intelligent agents to replace social objects in negotiating bill allocation in the background, improving the interactivity among social objects in multi-person consumption scenarios. Compared with direct default allocation or manually setting the allocation amount, this greatly enhances the intelligence of bill allocation. Specifically, in multi-person consumption scenarios, the bill to be paid is intelligently split directly, eliminating the need for a single payment bill. This improves the intelligence of bill splitting, and the N split sub-bills are directly shared with the N social objects in the multi-person consumption scenario, allowing each social object to view their own and others' sub-bills, achieving openness and transparency in bill allocation. Furthermore, the bill allocation process adds a confirmation step for each social object regarding the sub-bills, enhancing the interactivity among social objects in multi-person consumption scenarios. This interactivity provides social objects with an entry point to submit objections to sub-bills, thereby significantly improving the fairness of bill allocation.

[0208] Please see Figure 19 , Figure 19This illustration shows a flowchart of another payment processing method provided by an exemplary embodiment of this application. Figure 19 The payment processing method shown can be executed by a computer device. Taking the computer device as an example, which is a terminal held by the second social object, the payment processing method includes, but is not limited to, steps S1901-S1904:

[0209] S1901: When N social contacts collaboratively pay a bill, display the message receiving interface.

[0210] The message receiving interface is a service interface used by the second social object to display received notification messages; for example, this message receiving interface may be the conversation interface and message notification interface of a social application, independent of the SMS interface of the social application. In specific implementation, when the first social object performs a confirmation operation on its assigned sub-bills, it will send N sub-bills to the second social object. At this time, the message receiving interface is displayed on the second social object's side; this message receiving interface includes allocation messages related to the bills, so that the second social object can perceive the need to allocate the bills based on the allocation messages.

[0211] S1902: In response to a viewing operation of the allocation message, display the bill confirmation interface for the bill.

[0212] The second social contact can view the assigned messages in the message receiving interface. In response to this viewing action, the bill confirmation interface is displayed. This interface includes the sub-bills assigned to each social contact and the confirmation progress information for each sub-bill.

[0213] For example, a schematic diagram of displaying the bill confirmation interface on the second social media platform can be found here. Figure 20 ;like Figure 20 As shown, suppose a first social object shares N sub-bills with a second social object via social conversation messages. The second social object displays a message receiving interface with the first social object, which includes a triggerable allocation message 2001 related to the bill. When allocation message 2001 is triggered, a bill confirmation interface 2002 is displayed. This interface includes the N sub-bills and confirmation progress information for each sub-bill, as well as bill information (such as the resource amount the second social object needs to pay, the consumption type, etc.).

[0214] S1903: Receive confirmation from the target social object for the corresponding target sub-bill.

[0215] The target social object is the second social object. Specifically, the bill confirmation interface includes a confirmation control. When the second social object triggers the confirmation control, it means that the second social object is performing a confirmation operation on the target sub-bill it has been assigned to. At this time, the confirmation progress information of the target sub-bill corresponding to the second social object is "confirmed".

[0216] If a second social contact objects to their assigned sub-bill, they can trigger an action in the bill confirmation interface by modifying a component. This action indicates the second social contact disagrees with the bill allocation method, and a modification interface is displayed. This interface includes each consumption item associated with the bill and a modification description area for each item. The second social contact can select the message item whose configuration information they object to. If any consumption item is selected, the system receives policy modification information entered by the second social contact in the modification description area for that item. Furthermore, in response to the second social contact's submission of policy modification information, a notification message is output, indicating that the first social contact is waiting to resend the sub-bill. By supporting the second social contact in editing policy modification information for consumption items, the system helps them raise objections more effectively, improving the efficiency of negotiation between social contacts to some extent.

[0217] For example, a diagram illustrating the editing of strategy modification information by a second social object can be found here. Figure 21 ;like Figure 21 As shown, the bill confirmation interface includes a confirmation component 2101 and an objection component 2102. When the confirmation component 2101 is triggered, the confirmation progress information corresponding to the second social object is displayed as confirmed. When the objection component 2101 is triggered, a modification interface 2103 is displayed, which includes multiple consumption items, such as consumption item 2104, consumption item 2105, etc. If the target message item (such as consumption item 2104) is selected, the strategy modification information for the target consumption item is entered in the modification suggestion description area 2106. The bill confirmation interface also displays a submit option 2107. When the submit option 2107 is triggered, the strategy modification information is sent to the first social object, and the strategy modification information is displayed in the collaborative payment interface corresponding to the first social object.

[0218] S1904: After N social objects have performed confirmation operations on their respective assigned sub-bills, receive the payment operation performed by the target social object on the target sub-bill.

[0219] It should be noted that step S1904 and the aforementioned Figure 2The specific implementation process shown in step S203 in the embodiments is the same, and can be found in the foregoing relevant descriptions, which will not be repeated here.

[0220] In summary, in multi-person consumption scenarios, the embodiments of this application support N social objects corresponding to intelligent agents to negotiate in the background first, and then the N social objects to confirm or raise objections to the reference allocation strategy negotiated by the intelligent agents, which greatly ensures the reliability and rationality of bill sharing.

[0221] Based on the foregoing description, Figure 7 and Figure 19 The embodiments describe the implementation process of asynchronous sub-bill confirmation by the first social object and the second social object, respectively. To facilitate a better understanding of the process of collaborative bill payment through interaction between the first and second social object sides, the following will combine... Figure 22 The complete process of collaborative payment is presented from both the first and second social media user perspectives. For example... Figure 22 As shown, the steps for collaborative payment of bills by the first social object side and the second social object side may include, but are not limited to:

[0222] S1: The first social object initiates a multi-person collaborative payment, and the application activates the corresponding smart agent for each social object.

[0223] S2: The agent corresponding to the first social object requests the graph neural network to analyze the strength of social relationships and the social trust score between social objects. Specifically, the agent corresponding to the first social object sends a request for social relationship analysis to the graph neural network, which performs social relationship strength analysis and social score calculation, and returns the constructed social relationship network—the graph structure.

[0224] S3: The agent corresponding to the first social object identifies the identity information of each social object in the consumption scenario and initiates bill sharing negotiation with the agent corresponding to the second social object that is identified as a participant.

[0225] S4: The agent corresponding to the second social object transmits the consumption information of the second social object, such as consumption preferences and historical patterns, to the agent corresponding to the first social object.

[0226] S5: The agent corresponding to the first social object requests the consumption allocation engine to intelligently generate a reference allocation strategy. This consumption allocation engine can be deployed in a modular form within the agent corresponding to the first social object. During this process, multiple agents will provide allocation suggestion information to the consumption allocation engine, enabling the engine to generate a reference allocation strategy by analyzing the correlation between consumption items and each social object.

[0227] S6: The agent corresponding to the first social object can optimize the reference allocation strategy according to the adjustment operation performed by the first social object on the reference allocation strategy, or it can choose not to adjust the reference allocation strategy; the first social object will provide the application with N sub-bills after being split according to the reference allocation strategy for display. After the first social object confirms the N sub-bills, the application will display the N sub-bills to the second social object so that the second social object can provide feedback on the N sub-bills, such as confirmation or providing strategy modification information; the execution flow when the feedback is to provide strategy modification information can be found in the aforementioned relevant description.

[0228] S7: Once N social objects have confirmed N sub-bills, the application sends a payment request to the agent corresponding to each social object.

[0229] S8: Each AI will assess trust scores and risks, and determine security strategies corresponding to the risks for each social object.

[0230] S9: After each social user completes payment for their assigned sub-bill according to the payment security level indicated by the security policy, the application requests the settlement system to process the multi-party fund transfer. The settlement system responds to this request by processing the multi-party fund data transfer and returns the settlement result to the application.

[0231] S10: The application outputs the settlement completion status (i.e., payment result) to all social objects, and each agent records the payment data and the feedback from social objects regarding the settlement completion status.

[0232] In summary, the collaborative payment solution for consumption scenarios provided in this application has at least the following beneficial effects: ① Improved payment efficiency: Intelligent identity recognition and bill allocation reduce manual operation steps. ② Reduced social friction: Intelligent bill allocation considers the association between consumption items and social objects, generating a more reasonable bill allocation strategy and reducing disputes caused by unfair bill sharing. ③ Optimized payment experience: A simplified verification mechanism based on social trust provides a smoother payment experience for transactions among acquaintances. ④ Improved transaction security: Although the application provides simplified verification for highly trusted users, a high level of security is maintained through real-time risk detection and abnormal behavior detection. ⑤ Personalized payment experience: The intelligent agent learns from users' historical behavior and continuously optimizes the identity recognition and bill allocation algorithms, providing an increasingly personalized payment experience. ⑥ Improved merchant efficiency: For merchants generating bills, the settlement process in multi-person consumption scenarios is simplified, reducing the workload of waiters and customer waiting time. ⑦ Intelligent decision support: The intelligent agent can proactively provide payment suggestions, reducing the decision-making burden on social objects. ⑧ Group decision optimization: The multi-agent collaborative system can significantly reduce manual negotiation time and potential social friction. ⑨ Precise security assurance: The combination of context-aware dynamic trust assessment and intelligent agent security detection can provide more precise security assurance while maintaining a convenient payment experience.

[0233] The methods of the embodiments of this application have been described in detail above. To facilitate better implementation of the above-described solutions of the embodiments of this application, the apparatus of the embodiments of this application is provided below. In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0234] Figure 23 This application shows a schematic diagram of the structure of a payment processing apparatus according to an exemplary embodiment; the payment processing apparatus can be used to perform... Figure 2 , Figure 7 and Figure 19 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 23 The device includes the following units:

[0235] Display unit 2301 is used to display the sub-bill assigned to each social object when N social objects make collaborative payments on a bill. The total resource limit of the N sub-bills is equal to the resource limit of the bill; N is an integer greater than 1.

[0236] Processing unit 2302 is used to receive confirmation operations performed by the target social object for the corresponding target sub-bill; the target social object is any one of N social objects, and the target sub-bill is the sub-bill assigned to the target social object among the N sub-bills;

[0237] The processing unit 2302 is also used to receive the payment operation performed by the target social object on the target sub-bill after N social objects have performed confirmation operations on their respective assigned sub-bills.

[0238] In one implementation, when processing unit 2302 receives a payment operation performed by the target social object on the target sub-bill, it is specifically used for:

[0239] The payment interface is displayed, which includes security assessment information. This information is used to characterize the payment security level of the target social object; different payment security levels correspond to different payment methods.

[0240] Receive payment operations from the target social object for the target sub-bill according to the payment method corresponding to the payment security level;

[0241] Output the payment results interface, which displays the payment progress information for each social contact's assigned sub-bill.

[0242] In one implementation, the target social object is the first social object among N social objects that initiates collaborative payment for a bill, and the social objects among the N social objects other than the first social object are represented as the second social objects; the processing unit 2302 is used to display the sub-bills assigned to each social object when N social objects make collaborative payments for a bill, specifically for:

[0243] In response to the bill viewing operation, the bill interface is displayed; the bill interface includes bill details and a collaborative payment entry point;

[0244] In response to a triggered action on the collaborative payment entry point, the collaborative payment interface is displayed, which includes object identifiers for N social objects;

[0245] Based on the bill allocation operation performed in the collaborative payment interface, the sub-bills assigned to each social object are displayed.

[0246] In one implementation, the processing unit 2302, when displaying the collaborative payment interface in response to a trigger operation targeting the collaborative payment entry point, specifically performs the following functions:

[0247] In response to a triggered action on the collaborative payment entry point, the collaborative payment interface is displayed, which includes an object addition area;

[0248] In response to an object addition operation performed in the object addition area, display the object identifier of each of the N social objects in the object addition area;

[0249] The object addition operation includes at least one of the following: a selection operation performed on an object identifier from an object list, a selection operation on a recommended social object, a sharing operation to join the payment group to which the first social object belongs by sharing an invitation message, and an input operation on the object identifier of the social object.

[0250] In one implementation, the collaborative payment interface includes a recommendation allocation strategy, which defines the allocation rules for distributing bills among N social objects based on their consumption information. The processing unit 2302, when displaying the sub-bills allocated to each social object based on the bill allocation operation performed in the collaborative payment interface, specifically performs the following:

[0251] The recommended allocation strategy is displayed in the collaborative payment interface;

[0252] In response to the selection of the recommended allocation strategy, the sub-bills assigned to each social object are displayed; the N sub-bills are obtained by allocating the bills according to the allocation rules defined by the recommended allocation strategy.

[0253] In one implementation, the collaborative payment interface includes strategy configuration options. The processing unit 2302, when displaying the sub-bills assigned to each social object based on the bill allocation operation performed in the collaborative payment interface, specifically performs the following:

[0254] When the policy configuration option is triggered, the policy configuration interface is displayed;

[0255] It receives the strategy configuration operation executed in the strategy configuration interface and displays the sub-bills assigned to each social object; the N sub-bills are obtained by allocating the bills based on the setting allocation strategy generated by the strategy configuration operation.

[0256] In one implementation, each social object corresponds to an intelligent agent, which is used to negotiate bill allocation on behalf of the social object; the collaborative payment interface also includes an allocation negotiation area; the processing unit 2302, when displaying the sub-bills allocated to each social object, is specifically used for:

[0257] In the allocation negotiation area, the allocation suggestion information sent by each agent is displayed in the form of a session message; the target allocation suggestion information sent by the agent corresponding to the first social object is the recommended allocation strategy and / or the setting allocation strategy; the allocation suggestion information sent by the agent corresponding to any second social object among the N social objects (excluding the first social object) is generated from multiple evaluation dimensions, including the fairness dimension and the consumption habit dimension.

[0258] When the bill allocation negotiation ends, the collaborative payment interface displays N sub-bills obtained by allocating the bill based on the reference allocation strategy; the reference allocation strategy is generated based on the allocation suggestion information sent by N agents.

[0259] In one implementation, the collaborative payment interface also includes an adjustment component, and the processing unit 2302 is further used for:

[0260] In response to the triggering operation of the adjustment component, the strategy configuration interface is displayed; the strategy configuration interface includes at least one strategy configuration item, one strategy configuration item corresponds to one consumption item, and the strategy configuration item displays the corresponding configuration information in the reference allocation strategy;

[0261] Based on the adjustments made to the policy configuration items in the policy configuration interface, N first fine-tuned sub-bills are displayed, which are obtained by allocating the bills based on the adjusted reference allocation policy.

[0262] Processing unit 2302, when receiving confirmation operations performed by the target social object for the corresponding target sub-bill, is specifically used for:

[0263] Receive confirmation from the target social object for the target sub-bill among N first-fine-tuning sub-bills.

[0264] In one implementation, any social object among the N social objects, excluding the first social object, is represented as the second social object; the processing unit 2302 is further configured to:

[0265] Send N sub-bills to each second social object; and,

[0266] The confirmation waiting screen displays the confirmation progress information for each social object regarding its assigned sub-bill.

[0267] If strategy modification information related to the second social object is displayed in the confirmation waiting interface, the strategy configuration interface is displayed in response to the receiving operation of the strategy modification information. The strategy configuration interface includes at least one strategy configuration item, one strategy configuration item corresponds to one consumption item, and the strategy configuration item displays the corresponding configuration information in the reference allocation strategy. The target strategy configuration item related to the strategy modification information is highlighted in the strategy configuration interface.

[0268] In response to a policy fine-tuning operation on a target policy configuration item, display N second fine-tuning sub-bills obtained by allocating the bills based on the fine-tuning allocation policy generated by the policy fine-tuning operation.

[0269] In response to confirmation operations for N second-fine-tuning sub-bills, a confirmation waiting screen is displayed.

[0270] In one implementation, the confirmation progress information includes: confirmed, awaiting confirmation, and unconfirmed; the processing unit 2302 is further configured to:

[0271] When the confirmation progress information of the second social object for the assigned sub-bill is "awaiting confirmation" or "not confirmed", and the confirmation progress duration is greater than the duration threshold, a confirmation reply window will be displayed in the confirmation waiting interface. The confirmation reply window includes confirmation reply information, which is used to characterize the predicted feedback time of the second social object for the sub-bill. The confirmation reply window also includes confirmation prompt options.

[0272] In response to the triggering of the confirmation prompt option, a prompt message is sent to the second social object. The prompt message is used to prompt the second social object to confirm the bill or set the policy modification information for the assigned sub-bill.

[0273] In one implementation, the processing unit 2302 is further configured to:

[0274] Obtain target allocation suggestion information and receive allocation suggestion information sent by the agents corresponding to each second social object in response to the target allocation suggestion information;

[0275] Based on the allocation suggestion information and the target allocation suggestion information, the strategy is integrated and processed to generate a reference allocation strategy.

[0276] In one implementation, when the target allocation suggestion information is a recommended allocation strategy, the processing unit 2302, when obtaining the target allocation suggestion information, specifically performs the following:

[0277] Obtain consumption information from each secondary social contact;

[0278] Based on the message information of each of the N social objects, predict the association information between each social object and the bill;

[0279] Obtain the target allocation pattern and generate a recommended allocation strategy based on the associated information and the target allocation pattern.

[0280] In one implementation, the processing unit 2302, when predicting the association information between each social object and the bill based on the message information of each of the N social objects, specifically performs the following:

[0281] Perform scenario analysis on the consumption scenario to which the bill belongs, and obtain the scenario analysis results;

[0282] Based on the scenario analysis results, the social relationship information between N social objects and the behavioral pattern information of each social object, the identity information of each social object in the consumption scenario is identified.

[0283] Obtain at least one consumption item associated with the bill, and establish association information between each social object and each consumption item based on the identity information and message information corresponding to each social object, as well as the item characteristics of each consumption item; any association information includes matching information between the social object and the consumption item.

[0284] In one implementation, the target social object is the second social object among N social objects participating in the collaborative payment of the bill; the processing unit 2302, when displaying the sub-bill assigned to each social object during the collaborative payment of the bill by N social objects, specifically performs the following:

[0285] When N objects make collaborative payments on a bill, a message receiving interface is displayed, which includes allocation messages related to the bill.

[0286] In response to viewing the assigned message, the bill confirmation interface is displayed; the bill confirmation interface includes the sub-bill assigned to each social object, as well as the confirmation progress information for each sub-bill.

[0287] In one implementation, the bill confirmation interface includes a modification component, and the processing unit 2302 is further used for:

[0288] When the modification component is triggered, the modification interface is displayed. The modification interface includes: each consumption item associated with the bill, and a modification description area for each consumption item.

[0289] If any consumer item is selected, receive the policy modification information entered in the modification description area corresponding to any consumer item;

[0290] In response to the submission of policy modification information, a notification message is output, which indicates that the first social object should be waited for to resend the sub-bill.

[0291] According to one embodiment of this application, Figure 23The payment processing device shown can be constructed by combining the various units into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This can achieve the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the payment processing device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by multiple units working together. According to another embodiment of this application, the payment processing device can be executed by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), capable of performing functions such as... Figure 2 , Figure 7 and Figure 19 The computer program for each step involved in the corresponding method shown is used to construct, for example... Figure 23 The payment processing apparatus shown herein, and the payment processing method for implementing the embodiments of this application, are described. A computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and executed therein.

[0292] Based on the same inventive concept, the principle and beneficial effects of the computer device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the payment processing method in the embodiments of this application in solving the problem. Please refer to the principle and beneficial effects of the implementation of the method. For the sake of brevity, they will not be repeated here.

[0293] Figure 24 A schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application is shown. Please refer to... Figure 24The computer device includes a processor 2401, a communication interface 2402, and a computer-readable storage medium 2403. The processor 2401, communication interface 2402, and computer-readable storage medium 2403 can be connected via a bus or other means. The communication interface 2402 is used to receive and send data. The computer-readable storage medium 2403 can be stored in the computer device's memory and is used to store computer programs. The processor 2401 is used to execute the computer programs stored in the computer-readable storage medium 2403. The processor 2401 (or CPU) is the computing and control core of the computer device, suitable for implementing one or more computer programs, specifically suitable for loading and executing one or more computer programs to achieve corresponding method flows or corresponding functions.

[0294] This application embodiment also provides a computer-readable storage medium (Memory), which is a memory device in a computer device used to store programs and data. It is understood that the computer-readable storage medium here may include both the built-in storage medium in the computer device and extended storage media supported by the computer device. The computer-readable storage medium provides storage space that stores the processing system of the computer device. Furthermore, the storage space also stores one or more computer programs suitable for loading and execution by the processor 2401. These computer programs may be one or more computer programs. It should be noted that the computer-readable storage medium here may be high-speed RAM memory or non-volatile memory, such as at least one disk storage device; optionally, it may also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0295] In one embodiment, the computer device may be the terminal or server mentioned in the foregoing embodiments; the computer-readable storage medium stores one or more computer programs; the processor 2401 loads and executes the one or more computer programs stored in the computer-readable storage medium to implement the corresponding steps in the above-described payment processing method embodiments; in specific implementation, the one or more computer programs in the computer-readable storage medium are loaded and executed by the processor 2401 to execute the steps of the embodiments of this application; wherein, the steps of the embodiments of this application can be referred to the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0296] Based on the same inventive concept, the principle and beneficial effects of the computer device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the payment processing method in the embodiments of this application in solving the problem. Please refer to the principle and beneficial effects of the implementation of the method. For the sake of brevity, they will not be repeated here.

[0297] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described payment processing method.

[0298] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application 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 implementation should not be considered beyond the scope of this application.

[0299] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer programs. When a computer program is loaded and executed on a computer, it generates, in whole or in part, the processes or functions described in the embodiments of this application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in or transmitted through a computer-readable storage medium. The computer program can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video disks, DVDs), or semiconductor media (e.g., solid state disks, SSDs), etc.

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

Claims

1. A payment processing method, characterized in that, include: When N social contacts collaboratively pay a bill, the sub-bill assigned to each social contact is displayed, and the total resource limit of the N sub-bills equals the resource limit of the bill; N is an integer greater than 1. Receive confirmation from the target social object for the corresponding target sub-bill; the target social object is any one of the N social objects, and the target sub-bill is the sub-bill assigned to the target social object among the N sub-bills; After all N social objects have performed the confirmation operation on their respective assigned sub-bills, the payment operation performed by the target social object on the target sub-bill is received.

2. The method as described in claim 1, characterized in that, The step of receiving the payment operation performed by the target social object on the target sub-bill includes: The payment interface is displayed, which includes security assessment information. This security assessment information is used to characterize the payment security level corresponding to the target social object; different payment security levels correspond to different payment methods. Receive the payment operation performed by the target social object on the target sub-bill according to the payment method corresponding to the payment security level; The payment result interface displays the payment progress information for each of the social objects for their respective assigned sub-bills.

3. The method as described in claim 1 or 2, characterized in that, The target social object is the first social object among the N social objects that initiates collaborative payment for the bill, and the social objects among the N social objects other than the first social object are represented as the second social objects; when the N social objects make collaborative payments for the bill, the sub-bill assigned to each social object is displayed, including: In response to a bill viewing operation, the bill interface is displayed; the bill interface includes bill details and a collaborative payment entry point; In response to a trigger operation on the collaborative payment entry point, a collaborative payment interface is displayed, which includes object identifiers for N social objects; Based on the bill allocation operation performed in the collaborative payment interface, the sub-bills assigned to each of the social objects are displayed.

4. The method as described in claim 3, characterized in that, The response to a triggered operation on the collaborative payment entry point, displaying the collaborative payment interface, includes: In response to a triggered operation targeting the collaborative payment entry point, a collaborative payment interface is displayed, which includes an object addition area; In response to an object addition operation performed in the object addition area, the object identifier of each of the N social objects is displayed in the object addition area; The object addition operation includes at least one of the following: a selection operation performed on an object identifier from an object list, a selection operation on a recommended social object, a sharing operation to join the payment group to which the first social object belongs by sharing an invitation message, and an input operation on the object identifier of the social object.

5. The method as described in claim 3, characterized in that, The collaborative payment interface includes a recommendation allocation strategy, which defines the allocation rules for distributing the bill among N social objects based on their consumption information. The step of displaying the sub-bill assigned to each social object based on the bill allocation operation performed in the collaborative payment interface includes: The recommended allocation strategy is displayed on the collaborative payment interface; In response to the selection operation of the recommended allocation strategy, the sub-bill assigned to each social object is displayed; the N sub-bills are obtained by allocating the bills based on the allocation rules defined by the recommended allocation strategy.

6. The method as described in claim 3, characterized in that, The collaborative payment interface includes strategy configuration options. The step of displaying the sub-bills assigned to each social object based on the bill allocation operation performed in the collaborative payment interface includes: When the aforementioned policy configuration option is triggered, the policy configuration interface is displayed; The system receives the strategy configuration operation executed in the strategy configuration interface and displays the sub-bills assigned to each social object; the N sub-bills are obtained by allocating the bills based on the allocation strategy generated by the strategy configuration operation.

7. The method as described in claim 3, characterized in that, Each social object corresponds to an intelligent agent, which is used to negotiate bill allocation on behalf of the social object; The collaborative payment interface also includes an allocation negotiation area; The display of the sub-bills assigned to each of the aforementioned social objects includes: In the allocation negotiation area, the allocation suggestion information sent by each agent is displayed in the form of a session message; the target allocation suggestion information sent by the agent corresponding to the first social object is a recommended allocation strategy and / or a set allocation strategy; the allocation suggestion information sent by the agent corresponding to any second social object among the N social objects other than the first social object is generated from multiple evaluation dimensions, including fairness dimension and consumption habit dimension; When the bill allocation negotiation ends, the collaborative payment interface displays N sub-bills obtained by allocating the bill based on the reference allocation strategy; the reference allocation strategy is generated based on the allocation suggestion information sent by the N agents.

8. The method as described in claim 7, characterized in that, The collaborative payment interface also includes an adjustment component, and the method further includes: In response to a trigger operation on the adjustment component, a strategy configuration interface is displayed; the strategy configuration interface includes at least one strategy configuration item, each strategy configuration item corresponds to a consumption item, and the strategy configuration item displays the corresponding configuration information in the reference allocation strategy; Based on the adjustment operation for the policy configuration item in the policy configuration interface, N first fine-tuned sub-bills are displayed, which are obtained by allocating the bill based on the adjusted reference allocation policy. The confirmation operation performed by the target social object for the corresponding target sub-bill includes: Receive confirmation from the target social object for the target sub-bill among the N first fine-tuning sub-bills.

9. The method as described in claim 3, characterized in that, Any one of the N social objects, excluding the first social object, is represented as the second social object; after receiving the confirmation operation performed by the target social object for the corresponding target sub-bill, the method further includes: Send N of the aforementioned sub-bills to each of the second social objects; and The confirmation waiting interface is used to display the confirmation progress information of each social object for its assigned sub-bill; If strategy modification information related to the second social object is displayed in the confirmation waiting interface, a strategy configuration interface is displayed in response to the receiving operation of the strategy modification information; the strategy configuration interface includes at least one strategy configuration item, each strategy configuration item corresponds to a consumption item, and the strategy configuration item displays the corresponding configuration information in the reference allocation strategy; the strategy configuration interface highlights the target strategy configuration item related to the strategy modification information; In response to the policy fine-tuning operation for the target policy configuration item, N second fine-tuned sub-bills are displayed, which are obtained by allocating the bill based on the fine-tuning allocation policy generated by the policy fine-tuning operation. In response to confirmation operations for N second-fine-tuning sub-bills, a confirmation waiting interface is displayed.

10. The method as described in claim 9, characterized in that, The confirmation progress information includes: confirmed, awaiting confirmation, and unconfirmed; the method further includes: When the confirmation progress information of the second social object for the assigned sub-bill is "awaiting confirmation" or "not confirmed", and the confirmation progress duration is greater than the duration threshold, a confirmation reply window is displayed in the confirmation waiting interface; the confirmation reply window includes confirmation reply information, which is used to characterize the predicted feedback time of the second social object for the sub-bill; the confirmation reply window also includes a confirmation prompt option; In response to the triggering operation of the confirmation prompt option, a prompt message is sent to the second social object, the prompt message being used to prompt the second social object to confirm the assigned sub-bill or set the policy modification information.

11. The method as described in claim 3, characterized in that, Before receiving confirmation for the target sub-bill, the process also includes: Obtain target allocation suggestion information and receive allocation suggestion information sent by the intelligent agents corresponding to each second social object in response to the target allocation suggestion information; Based on the allocation suggestion information and the target allocation suggestion information, a strategy integration process is performed to generate a reference allocation strategy.

12. The method as described in claim 11, characterized in that, When the target allocation suggestion information is a recommended allocation strategy, obtaining the target allocation suggestion information includes: Obtain the consumption information of each of the second social objects; Based on the message information of each of the N social objects, predict the association information between each social object and the bill; Obtain the target allocation pattern, and generate the recommended allocation strategy based on the associated information and the target allocation pattern.

13. The method as described in claim 12, characterized in that, The step of predicting the association information between each of the N social objects and the bill based on the message information of each social object includes: Scenario analysis is performed on the consumption scenario to which the bill belongs, and the scenario analysis results are obtained; Based on the scenario analysis results, the social relationship information between the N social objects and the behavioral pattern information of each social object, the identity information of each social object in the consumption scenario is identified. Obtain at least one consumption item associated with the bill, and establish association information between each social object and each consumption item based on the identity information and message information corresponding to each social object, as well as the item characteristics of each consumption item; any association information includes matching information between the social object and the consumption item.

14. The method as described in claim 1 or 2, characterized in that, The target social object is the second social object among the N social objects participating in the collaborative payment of the bill; when the N social objects make a collaborative payment for the bill, the sub-bill assigned to each social object is displayed, including: When N social contacts collaboratively pay a bill, a message receiving interface is displayed, which includes allocation messages related to the bill. In response to the viewing operation of the allocation message, the bill confirmation interface of the bill is displayed; the bill confirmation interface includes the sub-bill assigned to each social object, and the confirmation progress information corresponding to each sub-bill.

15. The method as described in claim 14, characterized in that, The bill confirmation interface includes a modification component, and the method further includes: When the modification component is triggered, a modification interface is output; the modification interface includes: each consumption item associated with the bill, and a modification description area for each consumption item; When any of the aforementioned consumer items is selected, receive the strategy modification information entered in the modification description area corresponding to any of the aforementioned consumer items; In response to the submission of the policy modification information, a notification message is output, which indicates that the first social object should be waited for to resend the sub-bill.

16. A payment processing device, characterized in that, include: The display unit is used to display the sub-bill assigned to each social object when N social objects make collaborative payments on a bill. The total resource limit of the N sub-bills is equal to the resource limit of the bill. N is an integer greater than 1. The processing unit is used to receive a confirmation operation performed by the target social object for the corresponding target sub-bill; the target social object is any one of the N social objects, and the target sub-bill is the sub-bill allocated to the target social object among the N sub-bills; The processing unit is further configured to receive the payment operation performed by the target social object on the target sub-bill after all N social objects have performed the confirmation operation on their respective assigned sub-bills.

17. A computer device, characterized in that, include: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program that, when executed by the processor, implements the payment processing method as described in any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer application program, which, when executed, implements the payment processing method as described in any one of claims 1-15.

19. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the payment processing method as described in any one of claims 1-15.

Images