Transaction method, device, electronic device and computer-readable medium

Abstract

The present application discloses a transaction method, device, electronic device and computer-readable medium, and relates to the field of computer technology. The method includes: receiving a transaction request, determining a requester identifier and a joint activity identifier; generating a joint activity payment order corresponding to the requester identifier and sending it to the requester corresponding to the requester identifier, and determining the receivable payment status of the requester; determining whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status, and if not, refunding the receivable payment amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the joint activity, generating a resource transaction order, deducting virtual money from the agent account equal to the amount of the resource transaction order in real time, and determining the actual payment amount corresponding to the requester, and deducting the actual payment amount from the requester's account at a preset time. In this way, it is possible to achieve real-time deduction of fees from the agent, and offline equalization of the fees by the requester, thereby improving the flexibility of resource transactions.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a transaction method, device, electronic device, and computer-readable medium. Background Art

[0002] During the resource request process, each requester can purchase multiple resources separately. For some resources with transaction thresholds, requesters with smaller transaction volumes cannot trade and can only complete one-to-many and many-to-one transactions, all of which are one-time transactions with poor flexibility and cannot be split as needed.

[0003] In the process of implementing this application, the inventors discovered that the prior art has at least the following problems:

[0004] During the process of the requesting party requesting resources, the transaction cannot be split according to needs, and the flexibility of resource transactions is poor. Summary of the Invention

[0005] In view of this, the embodiments of the present application provide a transaction method, device, electronic device and computer-readable medium, which can solve the existing problem that when the requesting party requests resources, the transaction cannot be split as needed and the flexibility of resource transactions is poor.

[0006] To achieve the above objectives, according to one aspect of an embodiment of the present application, a transaction method is provided, comprising:

[0007] receiving a transaction request and determining a requester identifier and a joint activity identifier;

[0008] Generate a joint activity payment order corresponding to the requester ID and send it to the requester corresponding to the requester ID, and determine the receivable payment status of the requester;

[0009] Based on the receivable payment status, determine whether to start the joint activity corresponding to the joint activity identifier. If not, refund the receivable payment amount paid by the requesting party and end the transaction; if so, determine the target resource corresponding to the joint activity, and then generate a resource transaction order, deduct the virtual money of the agent account equal to the amount of the resource transaction order in real time, and determine the actual payment amount corresponding to the requesting party, and then deduct the actual payment amount from the requesting party's account at the preset time.

[0010] Optionally, before deducting the agent's virtual funds equal to the amount of the resource transaction order in real time, the method further includes:

[0011] In response to the initiation of a joint activity, the requesting party whose receivable payment status is paid is determined, and then the corresponding total assets of the joint activity are determined, and the agent is granted processing authority over the total assets of the joint activity, and then virtual funds equal to the total assets of the joint activity are added to the agent's account.

[0012] Optionally, determining the requester identifier includes:

[0013] Determine the resource identifier corresponding to the transaction request, and based on the resource identifier, determine the target requester group;

[0014] Generate invitation information based on the joint activity identifier;

[0015] Send invitation information to the target requester group, and receive feedback information from the target requester group on the invitation information;

[0016] The requester identity is determined based on the feedback information.

[0017] Optionally, before receiving the transaction request, the method further includes:

[0018] Receive a joint activity creation request, obtain the joint activity resource identifier, agent identifier, designated invitation requester identifier, activity cycle data, activity limit and recruitment identifier, and then build the corresponding joint activity and generate a joint activity identifier.

[0019] Optionally, determining the actual payment amount corresponding to the requesting party includes:

[0020] Obtain the transaction day activity deduction details corresponding to the virtual funds deducted from the agent's account;

[0021] Determine the matching ratio of the receivable and payment amounts of the requesting party participating in the joint activity;

[0022] Based on the ratio of receivable and payment amounts and the details of activity deductions on the transaction day, the shared expenses of the requesting parties participating in the joint activity are determined, and then the actual payment amount corresponding to the requesting parties participating in the joint activity is determined.

[0023] Optionally, before generating the joint activity payment order corresponding to the requester identifier and sending it to the requester corresponding to the requester identifier, the method further includes:

[0024] Determine the number of requesters based on the requester identifier;

[0025] In response to determining that the number of requesting parties is greater than two, a process of generating a joint activity payment order is performed.

[0026] Optionally, determining whether to start a joint activity corresponding to the joint activity identifier based on the receivable payment status includes:

[0027] Determine the number of paid requesters based on the receivable payment status;

[0028] In response to determining that the number of paid requesters is greater than two, an initiation process for the joint activity is performed.

[0029] Optionally, after deducting the actual payment amount from the requester's account at a preset time, the method further comprises:

[0030] At the preset time, determine the total amount of actual payment deducted from the requester's account and the total amount of virtual gold deducted from the agent's account, and judge whether the total amount of actual payment and the total amount of virtual gold are equal. If so, no processing will be done; otherwise, the alarm process will be executed.

[0031] In addition, the present application also provides a transaction device, including:

[0032] a receiving unit configured to receive a transaction request and determine a requester identifier and a joint activity identifier;

[0033] a receivable payment status determining unit configured to generate a joint activity payment order corresponding to the requester identifier and send the order to the requester corresponding to the requester identifier, and determine the receivable payment status of the requester;

[0034] The transaction unit is configured to determine whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status; if not, refund the receivable payment amount paid by the requesting party and end the transaction; if so, determine the target resource corresponding to the joint activity, and then generate a resource transaction order, deduct the virtual money of the agent account equal to the amount of the resource transaction order in real time, and determine the actual payment amount corresponding to the requesting party, and then deduct the actual payment amount from the requesting party's account at a preset time.

[0035] Optionally, the transaction device further includes a virtual money increasing unit configured to:

[0036] In response to the initiation of a joint activity, the requesting party whose receivable payment status is paid is determined, and then the corresponding total assets of the joint activity are determined, and the agent is granted processing authority over the total assets of the joint activity, and then virtual funds equal to the total assets of the joint activity are added to the agent's account.

[0037] Optionally, the receiving unit is further configured to:

[0038] Determine the resource identifier corresponding to the transaction request, and based on the resource identifier, determine the target requester group;

[0039] Generate invitation information based on the joint activity identifier;

[0040] Send invitation information to the target requester group, and receive feedback information from the target requester group on the invitation information;

[0041] The requester identity is determined based on the feedback information.

[0042] Optionally, the transaction device further includes a joint activity construction unit configured to:

[0043] Receive a joint activity creation request, obtain the joint activity resource identifier, agent identifier, designated invitation requester identifier, activity cycle data, activity limit and recruitment identifier, and then build the corresponding joint activity and generate a joint activity identifier.

[0044] Optionally, the transaction unit is further configured to:

[0045] Obtain the transaction day activity deduction details corresponding to the virtual funds deducted from the agent's account;

[0046] Determine the matching ratio of the receivable and payment amounts of the requesting party participating in the joint activity;

[0047] Based on the ratio of receivable and payment amounts and the details of activity deductions on the transaction day, the shared expenses of the requesting parties participating in the joint activity are determined, and then the actual payment amount corresponding to the requesting parties participating in the joint activity is determined.

[0048] Optionally, the receivable payment status determining unit is further configured to:

[0049] Determine the number of requesters based on the requester identifier;

[0050] In response to determining that the number of requesting parties is greater than two, a process of generating a joint activity payment order is performed.

[0051] Optionally, the transaction unit is further configured to:

[0052] Determine the number of paid requesters based on the receivable payment status;

[0053] In response to determining that the number of paid requesters is greater than two, an initiation process for the joint activity is performed.

[0054] Optionally, the transaction device further comprises an alarm unit configured to:

[0055] At the preset time, determine the total amount of actual payment deducted from the requester's account and the total amount of virtual gold deducted from the agent's account, and judge whether the total amount of actual payment and the total amount of virtual gold are equal. If so, no processing will be done; otherwise, the alarm process will be executed.

[0056] In addition, the present application also provides a transaction electronic device, including: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by one or more processors, the one or more processors implement the transaction method as described above.

[0057] In addition, the present application also provides a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, the transaction method as described above is implemented.

[0058] One embodiment of the above invention has the following advantages or beneficial effects: the present application determines the requester ID and the joint activity ID by receiving a transaction request; generates a joint activity payment order corresponding to the requester ID and sends it to the requester corresponding to the requester ID, and determines the receivable payment status of the requester; determines whether to start the joint activity corresponding to the joint activity ID based on the receivable payment status, and if not, refunds the receivable payment amount paid by the requester and ends the transaction; if so, determines the target resource corresponding to the joint activity, and then generates a resource transaction order, deducts the virtual money of the agent account equal to the amount of the resource transaction order in real time, and determines the actual payment amount corresponding to the requester, and then deducts the actual payment amount from the requester's account at a preset time. In this way, when multiple requesters request resources from multiple suppliers, the agent can be charged in real time, and the requester can evenly account for the payment offline, thereby improving the flexibility of resource transactions.

[0059] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] The accompanying drawings are provided to facilitate a better understanding of the present application and are not intended to limit the present application.

[0061] Figure 1 is a schematic diagram of the main process of the transaction method according to the first embodiment of the present application;

[0062] Figure 2 is a schematic diagram of the main process of the transaction method according to the second embodiment of the present application;

[0063] Figure 3 is an interactive schematic diagram of a transaction method according to an embodiment of the present application;

[0064] Figure 4 is a schematic diagram illustrating the structure of a transaction method according to an embodiment of the present application;

[0065] Figure 5 This is a schematic diagram of the main process of the transaction method according to the third embodiment of the present application;

[0066] Figure 6 1 is a schematic diagram of a joint activity creation process according to a transaction method according to an embodiment of the present application;

[0067] Figure 7 1 is a schematic diagram of a joint activity transaction process according to a transaction method according to an embodiment of the present application;

[0068] Figure 8 1 is a schematic diagram of a joint activity execution flow of a transaction method according to an embodiment of the present application;

[0069] Figure 9is a schematic diagram of the main units of a transaction device according to an embodiment of the present application;

[0070] Figure 10 is an exemplary system architecture diagram to which embodiments of the present application may be applied;

[0071] Figure 11 It is a structural diagram of a computer system of a terminal device or server suitable for implementing an embodiment of the present application. DETAILED DESCRIPTION

[0072] The following describes exemplary embodiments of the present application in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. The acquisition, storage, use, processing, etc. of data in the technical solution of this application comply with the relevant provisions of national laws and regulations.

[0073] Figure 1 This is a schematic diagram of the main process of the transaction method according to the first embodiment of the present application. Figure 1 As shown, the transaction methods include:

[0074] Step S101: receiving a transaction request and determining a requester identifier and a joint activity identifier.

[0075] In this embodiment, the execution subject of the transaction method (for example, a server) can receive transaction requests initiated by various requesting parties through a wired connection or a wireless connection. It is understandable that the transaction request can be initiated by one requesting party or by multiple requesting parties. The embodiment of the application does not specifically limit the number of requesting parties corresponding to the transaction request. Figure 4 As shown, the requester is the resource purchaser. The resource purchasers may include requester 1, requester 2, requester 3, requester 4, requester 5, etc. The requester identifier may be the name of the requester (in Chinese characters or pinyin), the contact information of the requester, etc. This application does not limit the specific content and form of the requester identifier. The joint activity identifier is a joint activity identifier corresponding to the requester identifier determined according to the transaction request of the requester, for example, 1 and 2, respectively corresponding to Figure 4 Joint activity 1 and joint activity 2.

[0076] Specifically, determining the requester identifier includes:

[0077] Determine the resource identifier corresponding to the transaction request, and based on the resource identifier, determine the target requester group. For example, Figure 4In the business-level resources 1, 2, 3, and 4, 1, 2, 3, and 4 are resource identifiers. In the resource preparation stage, the execution entity creates resource data in the business middle-end system based on the resource data provided by the resource docking system provided by the supplier, defines a platform-wide unique standard code for each resource, namely the resource identifier, and binds the supplier information to which the resource belongs. Configure the resources on at least one publisher side, publish the resources on the publisher, and set the basic attribute fields required by the current publisher's business, including unit price, discount, support time, etc. Publish resources on the publisher, for example Figure 4 In the example, resource 1 is published on publisher 1, resource 2 is published on publisher 2, resource 1 is published on publisher 3, and resource N is published on publisher N. The present application embodiment does not specifically limit the resources published on the publisher, and there is no fixed correspondence between the publisher and the resources. For example, Figure 4 As shown, when the execution subject determines that the resource identifiers corresponding to the transaction request are 1 and N, it can be determined that the target requester group includes Figure 4 Requester 1, Requester 2, Requester 3, Requester 4, Requester 5 in .

[0078] Generate invitation information based on the joint activity ID. For example, when the joint activity ID is 2, based on Figure 4 The joint activity 2 generates invitation information for participating in the joint activity 2. The invitation information may include the identifiers of each requester included in the target requester group and the joint activity identifier, as well as other publishing resources, agent information, designated invitation requesters, and activity cycle data including activity start time, activity end time, activity limit, whether the system is recruiting, and other information.

[0079] Send invitation information to the target requester group, and receive feedback information on the invitation information from the target requester group.

[0080] Specifically, the feedback information includes, for example, whether all the target requesting parties have clicked a "Confirm Invitation" button, or whether they have replied with a number (eg, 1) or a letter (yes) indicating acceptance of the invitation.

[0081] The requester identity is determined based on the feedback information.

[0082] Specifically, when the executing entity determines that the feedback information contains relevant information indicating "confirmation of invitation", for example, a reply "1" or a reply "yes" is received, the identifier corresponding to the requesting party whose reply indicates "confirmation of invitation" is determined as the requesting party identifier corresponding to the joint activity 2.

[0083] Specifically, before receiving the transaction request, the method further includes:

[0084] Receive a joint activity creation request, obtain the joint activity resource identifier, agent identifier, designated invitation requester identifier, activity cycle data, activity limit and recruitment identifier, and then build the corresponding joint activity and generate a joint activity identifier.

[0085] For example, the executing entity can create a joint activity through the joint activity system, define a unique plan ID, and bind the joint activity attributes such as multiple publishing resources, agent information, designated invitation requester, and activity cycle data including activity start time, activity end time, activity limit, and whether system recruitment is performed to the joint activity plan.

[0086] Step S102: Generate a payment order for the joint activity corresponding to the requester ID and send it to the requester corresponding to the requester ID, and determine the receivable payment status of the requester.

[0087] Specifically, before generating a joint activity payment order corresponding to the requester identifier and sending it to the requester corresponding to the requester identifier, the method further includes: determining the number of requesters based on the requester identifier; and executing a generation process of the joint activity payment order in response to determining that the number of requesters is greater than two.

[0088] Step S103: determining whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status.

[0089] Specifically, determining whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status includes:

[0090] Determine the number of paid requesters based on the receivable payment status;

[0091] In response to determining that the number of paid requesters is greater than two, an initiation process for the joint activity is performed.

[0092] The amount payable by the requesting party is frozen as follows: Figure 5 The request of the business middle-office system shown is placed in the account.

[0093] Step S104: If not, the payment amount paid by the requesting party is refunded and the transaction is terminated.

[0094] If the number of paid requesters is less than two, the amount paid by the requesters will be refunded.

[0095] Step S105: If yes, determine the target resources corresponding to the joint activity, and then generate a resource transaction order, deduct the virtual money of the agent's account equal to the amount of the resource transaction order in real time, and determine the actual payment amount corresponding to the requesting party, and then deduct the actual payment amount from the requesting party's account at a preset time.

[0096] If the number of paid requesters is greater than two, a joint activity is initiated. Figure 4 The right to handle the total assets of the joint activity of agent 2 (the total assets of all requesting parties that have been frozen) corresponding to the joint activity 2 shown, and the virtual money equivalent to the total transaction amount of the joint activity is added to the agent's account. Determine the target resources corresponding to the joint activity, such as Figure 4 Resource 1 on publisher 3 and resource N on publisher N in the example above are used to generate resource transaction orders corresponding to resource 1 and resource N. Real-time billing is used to deduct virtual funds from the agent's account equal to the amount of the resource transaction order, and the actual payment amount corresponding to the requester is determined. Offline amortized billing is then performed, that is, the actual payment amount is deducted from the requester's account at a preset time.

[0097] Specifically, determining the actual payment amount corresponding to the requesting party includes:

[0098] Obtain the transaction day activity deduction details corresponding to the deducted virtual funds from the agent's account; determine the payable / receivable amount ratio for the requesting parties participating in the joint activity, for example, Participant 1: Participant 2: Participant 3: Participant 4: Participant 5 = 1:2:3:4:5. Based on the payable / receivable amount ratio and the transaction day activity deduction details, determine the shared expenses for the requesting parties participating in the joint activity, and then determine the actual payment amount for the requesting parties participating in the joint activity. For example, if the deduction for an activity plan in the joint activity is 15 yuan, the shared expenses for the requesting parties participating in the joint activity will be 1 yuan, 2 yuan, 3 yuan, 4 yuan, and 5 yuan, respectively, based on the above payable / receivable amount ratio.

[0099] The receivable payment amount is the amount of the joint activity payment order paid by each requesting party. The receivable payment amount of each requesting party can be the same or different, depending on the specific resource requirements of each requesting party, and this embodiment of the application does not limit this.

[0100] Specifically, after deducting the actual payment amount from the requester's account at a preset time, the transaction method further includes:

[0101] At the preset time, determine the total amount of actual payment deducted from the requester's account and the total amount of virtual gold deducted from the agent's account, and judge whether the total amount of actual payment and the total amount of virtual gold are equal. If so, no processing will be done; otherwise, the alarm process will be executed.

[0102] When the executing entity determines that the sum of the actual payment amounts of each requesting party deducted is not equal to the amount of the deduction details of the transaction day activity, it indicates that there may be a problem in the calculation and an alarm is issued.

[0103] This embodiment receives a transaction request, determines the requester ID and the joint activity ID; generates a joint activity payment order corresponding to the requester ID and sends it to the requester corresponding to the requester ID, determines the receivable payment status of the requester; determines whether to start the joint activity corresponding to the joint activity ID based on the receivable payment status, and if not, refunds the receivable payment amount paid by the requester and ends the transaction; if so, determines the target resource corresponding to the joint activity, and then generates a resource transaction order, deducts the virtual money of the agent account equal to the amount of the resource transaction order in real time, and determines the actual payment amount corresponding to the requester, and then deducts the actual payment amount from the requester's account at a preset time. In this way, when multiple requesters request resources from multiple suppliers, the agent can be charged in real time, and the requester can evenly account for the payment offline, thereby improving the flexibility of resource transactions.

[0104] Figure 2 This is a schematic diagram of the main flow of the transaction method according to the second embodiment of the present application. Figure 2 As shown, the transaction methods include:

[0105] Step S201: receiving a transaction request and determining a requester identifier and a joint activity identifier.

[0106] When the execution entity detects that it has received a transaction request from a requesting party, it can detect whether it corresponds to a joint activity recruited by the system. Specifically, it can determine whether it corresponds to a joint activity recruited by the system by determining whether the transaction request includes a system recruitment identifier, such as XTZM.

[0107] For example, Figure 6 As shown, the steps for creating a joint activity include: starting with the execution entity configuring the activity resource list, configuring the activity invitation requestors (which may include requestors with the same resource requirements), and configuring activity attributes such as quota, activity period, and agent convenience. The process then determines whether the activity is being recruited by the system. If so, the target requestor is analyzed and the activity information is pushed. If not, the activity information is pushed to a designated requestor (e.g., the requestor that sent the transaction request). The designated requestor then proactively invites the identified target requestor to create the joint activity. Upon successful creation of the joint activity, the joint activity creation process ends.

[0108] For example, a requester or business entity creates a joint event through the joint event system, defines a unique plan ID, and binds the joint event attributes, including multiple publishing resources, agent information, designated invitees, and event cycle data, including the event start and end time, activity quota, and whether system recruitment is required, to the event plan. After creation is complete, the execution entity sends a joint event reminder message to the designated invitee. If the event requires system recruitment, the execution entity analyzes the target group of invitees with similar requirements and sends a joint event reminder. Requesters who receive the joint event reminder message can also use the event invitation function to send joint event invitation messages to the target group of invitees. The target group of invitees with similar requirements can be automatically determined by the business entity's server based on accumulated business data. For example, the target group of invitees can be determined based on the requester's historical transaction data. The requester's resource transactions reflect their resource preferences, and this historical transaction data can be used to determine the target group of invitees for the joint event. Therefore, when a group of invitees with similar requirements participate in a joint event, they can increase the probability of resource transactions and improve resource optimization.

[0109] Step S202: Generate a payment order for the joint activity corresponding to the requester ID and send it to the requester corresponding to the requester ID, and determine the receivable payment status of the requester.

[0110] Step S203: determining whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status.

[0111] Step S204: If not, the payment amount paid by the requesting party is refunded and the transaction is terminated.

[0112] Step S205: If yes, in response to the initiation of the joint activity, the requesting party whose receivable payment status is paid is determined, and then the corresponding total assets of the joint activity are determined, and the agent is granted the processing authority for the total assets of the joint activity, and then virtual funds equal to the total assets of the joint activity are added to the agent's account.

[0113] When the joint activity is launched, the agent bound to the joint activity plan code will have the right to handle the total assets of the joint activity (the total assets of all requesting parties that have been frozen), and virtual gold equivalent to the total transaction amount of the joint activity will be added to the agent's system account.

[0114] For example, Figure 7 As shown, the transaction process of joint activities is as follows:

[0115] Start (start) The requester initiates a joint activity transaction. The execution entity checks whether there are more than two requesters initiating the transaction. If not, the transaction is terminated. If so, the payment order is pushed to the requester. If the requester pays successfully, the frozen payment amount is added to the requester's account. Before the activity starts, it is checked whether there are more than two requesters who have successfully paid. If so, the joint activity is started, and the agent adds virtual gold of equal value. If not, the payment amount is refunded and the transaction is terminated.

[0116] For example, the requester initiates a transaction request to the joint activity based on its own needs; the request data carries the requester's transaction asset information for the joint activity and the joint activity plan identifier (joint activity plan ID); verification is performed at the end of the activity requirement cycle. In response to at least two requesters initiating joint activity transaction requests, the joint activity is successfully triggered, and the requester's payment order is pushed to all transaction requesters. The order carries the requester's unique code, the joint activity plan code, and the payment amount. The requester receives the payment order and uses the capabilities provided by the business middle-office system to make the payment. After the payment is successful, the requester's financial accounts receivable are generated and the accounts receivable are deposited into the accounting entries; the requester's (virtual gold) asset balance in the business middle-office system (agent) is increased. The requester is bound to the joint activity plan code. After the joint activity transaction cycle ends, the ratio of the requester's transaction assets to total assets in the joint activity is recorded, and finally the joint activity is started according to the start time. When the joint activity is launched, the agent bound to the joint activity plan code will have the right to handle the total assets of the joint activity (the total assets of all requesting parties that have been frozen), and virtual gold equivalent to the total transaction amount of the joint activity will be added to the agent's system account.

[0117] Step S206: Determine the target resources corresponding to the joint activity, and then generate a resource transaction order. Deduct virtual funds from the agent's account equal to the amount of the resource transaction order in real time, and determine the actual payment amount corresponding to the requesting party, and then deduct the actual payment amount from the requesting party's account at a preset time.

[0118] like Figure 8 As shown, the joint activity execution process is as follows:

[0119] On the start (T) trading day, agent G initiates resource transaction A. On T, agent G initiates resource transaction B. On T, agent GG initiates resource transaction N. The agent's virtual funds are deducted on the trading day. The agent's virtual funds are deducted, and the deduction details for the joint activity on day T are recorded (including the joint activity plan batch, agent ID, requester ID, and activity amount). The requester's shared payment calculation begins on day T+1. The specific steps are as follows: Query the deduction details for the joint activity on day T. Based on the joint activity requester funding ratio (i.e., the ratio of the actual receivable and actual payment amounts paid by each requester for the joint activity payment order when the joint activity was first created, for example, Participant 1: Participant 2: Participant 3: Participant 4: Participant 5 = 1:2:3:4:5), deduct the requester's actual payment amount and record the shared payment amount. If the deduction is successful, synchronize the actual payment data with the financial data. Verify the total amount of the deduction details with the total amount of the deducted actual payment for each requester. If the two are not equal, execute the alarm process. At the end of the activity, the fees shared by each requester are consolidated and the balance of each requester's account is deducted.

[0120] For example, based on the requester's needs and resource utilization, the agent selects target resources from a set of publisher information and resource standard codes that match the joint activity plan code, generating resource trade orders in batches and at different times. The agent then identifies the supplier to whom the target resource belongs in the order and processes the identified supplier's resource information with the supplier's docking system for settlement. After each resource trade order is settled, the agent's virtual fund balance is deducted in real time based on the order amount. On day T+1, all resource trade orders for day T are aggregated and, based on the requester asset allocation associated with the joint activity plan code, expenses are allocated offline to each requester. The actual receipts are generated and recorded in the accounting journal (receivable minus actual receipts). Upon expiration of the joint activity, all requesters' expenses are consolidated and allocated, and the requester's asset balance in the business system is deducted. T: Transaction day.

[0121] Figure 3 This is an interactive diagram of the transaction method according to the embodiment of the present application. The transaction method of the embodiment of the present application is applied to the scenario where multiple requesters request resources from multiple suppliers. The solution of the embodiment of this specification can be applied to joint activity transactions and resource processing scenarios, such as Figure 3As shown, the transaction method of the embodiment of the present application involves at least the following five subjects: the supplier of resources, referred to as the supplier in this embodiment, which can be used to provide resources, for example, it can be a subject such as a resource manufacturer; the publisher of resources, referred to as the publisher in this embodiment, which refers to the business system that publishes resources. The resources published by the publisher may include resources from the supplier, as well as other resources that do not come from the supplier. The publisher may obtain resources from the supplier or through other means, which is not limited in this embodiment. The publisher of joint activities of resources, referred to as the joint activity publisher in this embodiment, which only publishes the requesting party or agent of the joint activity, are collectively referred to as the joint activity publisher. The joint activity publisher refers to the party that combines and publishes more than one published resource to form a resource publishing set, and trades the resource publishing set with the requesting party. The resource requester, referred to as the requester in this embodiment, is the party that obtains resources, needs to use resources, trades with the joint activity publisher, and the resource collection published by the joint activity publisher; the resource agent, referred to as the agent in this embodiment, is the party that handles the transaction orders between the joint activity publisher and multiple requesters, and trades with the supplier for the resources provided by the supplier.

[0122] There can be one, two, or more suppliers, each of which can provide at least one resource category. There can also be at least one publisher, each of which can publish at least one resource category from at least one supplier. There can also be at least one joint activity publisher, each of which can publish a resource release set. There can also be at least one requester, which can obtain at least one resource release set from at least one joint activity publisher. There can be one, two, or more brokers, each of which can provide and process transaction orders for at least one joint activity. Figure 3 For the convenience of illustration, a schematic diagram of multiple suppliers, multiple publishers, multiple joint activity publishers, multiple requesters, and multiple brokers is shown.

[0123] In a business scenario, there are many suppliers of resources, and the resources provided by each supplier have their own characteristics. There are also certain thresholds for the resources of some high-quality suppliers. In order to achieve optimal processing of resources, an embodiment of this specification provides a resource processing device, wherein the subject applying the above-mentioned device can be another subject different from the above-mentioned suppliers, publishers, joint activity publishers, agents and requesters, which is called a business party in this embodiment. The business party can provide a business platform, and all of the above parties can serve as users of the business platform, and the business platform provides resource processing services. As an example, the business party can provide clients to suppliers, publishers, joint activity publishers, agents and requesters respectively, and the suppliers, publishers, joint activity publishers, agents and requesters provide their own clients to communicate with the business platform.

[0124] The target resources in the embodiments of this application can refer to different objects in different application scenarios. For example, they can refer to software resources such as processing threads or bandwidth resources, hardware resources such as memory, hard disks, or servers, physical objects such as commodities, personal service resources such as cleaning, running errands, or haircuts, or virtual resources such as internet advertising, electronic currency, and transaction discounts. In actual applications, suppliers generally hope that as many requesters as possible will be able to trade the target resources they provide.

[0125] like Figure 5 As shown, it is a main flow chart of the transaction method according to the third embodiment of the present application. The supplier docking system publishes resources (including resource identifiers) to each business system. Interacting with the joint activity system, the joint activity system selects multiple resources from each business system, selects an agent to create a joint activity and binds it to the joint activity. The joint activity system creates a joint activity, publishes it, and pushes the joint activity notification to the requester of the business middle-office system to push it to each requester. The requester initiates a transaction request, and the joint activity system checks whether there are more than two requesters who have made transaction requests. If so, the payment order is pushed to each requester. The requester pays successfully, increases the assets corresponding to the payment amount in the requester's account and freezes them, calls the financial system to record the requester's receivables, and checks whether there are more than two requesters who have made successful payments. If so, the joint activity is started. The requester and the agent of the business middle-office system send a joint activity start notification, and increase the virtual money equivalent to the activity payment amount in the agent account of the business middle-office system. The agent of the business middle office system uses virtual funds to initiate resource transactions with each business system. Each business system purchases the requested resources from the corresponding supplier (i.e., the vendor). After each business system successfully pays for the purchased resources, the agent's (i.e., the agent's) virtual funds are deducted in real time. The requester's fees are evenly distributed offline for T (transaction date) + 1 day, and the actual financial receipts are recorded. When the joint activity ends, the agent of the business middle office system sends a joint activity end notification to the requester of the business middle office system. The agent integrates the evenly distributed fees of the requester and deducts the corresponding actual assets of each requester from the requester's account, that is, deducts the total actual assets of the requester.

[0126] The three execution phases of this embodiment are sequentially divided into: resource preparation, joint activity publishing, and joint activity execution. This enables many-to-many transactions between requesters and suppliers. By adding agents between requesters and suppliers, unified resource allocation is achieved. A design architecture that combines real-time agent deductions with offline requester deductions, using a real-time pull and scheduled push method, implements a distributed financial data architecture based on activity.

[0127] Figure 9 Schematic diagram of the main units of the transaction device according to the embodiment of the present application. Figure 9As shown, the transaction device includes a receiving unit 901, a receivable payment status determining unit 902 and a transaction unit 903.

[0128] The receiving unit 901 is configured to receive a transaction request and determine a requester identifier and a joint activity identifier.

[0129] The receivable payment status determining unit 902 is configured to generate a joint activity payment order corresponding to the requester identifier and send the order to the requester corresponding to the requester identifier, and determine the receivable payment status of the requester.

[0130] The transaction unit 903 is configured to determine whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status. If not, the receivable payment amount paid by the requesting party is refunded and the transaction is terminated; if so, the target resource corresponding to the joint activity is determined, and a resource transaction order is generated, and the virtual money of the agent account equal to the amount of the resource transaction order is deducted in real time, and the actual payment amount corresponding to the requesting party is determined, and the actual payment amount is deducted from the requesting party's account at a preset time.

[0131] In some embodiments, the transaction device further includes Figure 9 The virtual money increasing unit not shown in the figure is configured to: in response to the initiation of a joint activity, determine the requesting party whose receivable payment status is paid, and then determine the corresponding total assets of the joint activity, grant the agent the processing authority over the total assets of the joint activity, and then increase the virtual money of the same value as the total assets of the joint activity in the agent's account.

[0132] In some embodiments, the receiving unit 901 is further configured to: determine the resource identifier corresponding to the transaction request, and determine the target requester group based on the resource identifier; generate invitation information based on the joint activity identifier; send the invitation information to the target requester group, and receive feedback information from the target requester group on the invitation information; and determine the requester identifier based on the feedback information.

[0133] In some embodiments, the transaction device further includes Figure 9 The joint activity construction unit (not shown) is configured to: receive a joint activity creation request, obtain a joint activity resource identifier, an agent identifier, a designated invitation requester identifier, activity cycle data, an activity limit, and a recruitment identifier, and then construct a corresponding joint activity and generate a joint activity identifier.

[0134] In some embodiments, the transaction unit 903 is further configured to: obtain the transaction day activity deduction details corresponding to the virtual gold deducted from the agent account; determine the receivable and payment amount ratio of the requesting party participating in the joint activity; based on the receivable and payment amount ratio and the transaction day activity deduction details, determine the shared expenses of the requesting party participating in the joint activity, and then determine the actual payment amount corresponding to the requesting party participating in the joint activity.

[0135] In some embodiments, the receivable payment status determining unit 902 is further configured to: determine the number of requesting parties according to the requesting party identifier; and execute a process of generating a joint activity payment order in response to determining that the number of requesting parties is greater than two.

[0136] In some embodiments, the transaction unit 903 is further configured to: determine the number of paid requesting parties according to the receivable payment status; and execute a start process of the joint activity in response to determining that the number of paid requesting parties is greater than two.

[0137] In some embodiments, the transaction device further includes Figure 9 The alarm unit not shown in the figure is configured to: at a preset time, determine the total amount of actual payment deducted from the requester's account and the total amount of virtual gold deducted from the agent's account, and judge whether the total amount of actual payment and the total amount of virtual gold are equal. If so, no processing will be performed; otherwise, the alarm process will be executed.

[0138] It should be noted that the transaction method and transaction device of the present application have a corresponding relationship in terms of specific implementation content, so the repeated content will not be explained again.

[0139] Figure 10 An exemplary system architecture 1000 is shown to which the transaction method or transaction device according to the embodiments of the present application can be applied.

[0140] like Figure 10 As shown, system architecture 1000 may include terminal devices 1001, 1002, and 1003, a network 1004, and a server 1005. Network 1004 is used to provide a medium for communication links between terminal devices 1001, 1002, and 1003 and server 1005. Network 1004 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0141] Users can use terminal devices 1001, 1002, and 1003 to interact with server 1005 via network 1004 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 1001, 1002, and 1003, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0142] The terminal devices 1001 , 1002 , and 1003 may be various electronic devices having a transaction processing screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0143] Server 1005 can be a server that provides various services, such as a background management server that provides support for tasks submitted by users using terminal devices 1001, 1002, and 1003 (only as an example). The background management server can receive a transaction request, determine the requester identifier and the joint activity identifier; generate a joint activity payment order corresponding to the requester identifier and send it to the requester corresponding to the requester identifier, determine the receivable payment status of the requester; determine whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status, and if not, refund the receivable payment amount paid by the requester and end the transaction; if so, determine the target resource corresponding to the joint activity, and then generate a resource transaction order, deduct the virtual money of the agent account equal to the amount of the resource transaction order in real time, and determine the actual payment amount corresponding to the requester, and then deduct the actual payment amount from the requester's account at a preset time. In this way, when multiple requesters request resources from multiple suppliers, the agent can be charged in real time, and the requester can evenly account for the payment offline, thereby improving the flexibility of resource transactions.

[0144] It should be noted that the transaction method provided in the embodiment of the present application is generally executed by the server 1005 , and accordingly, the transaction device is generally set in the server 1005 .

[0145] It should be understood that Figure 10 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0146] Reference below Figure 11 , which shows a structural diagram of a computer system 1100 of a terminal device suitable for implementing an embodiment of the present application. Figure 11 The terminal device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0147] like Figure 11 As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1102 or a program loaded from a storage unit 1108 into a random access memory (RAM) 1103. Various programs and data required for the operation of the computer system 1100 are also stored in the RAM 1103. The CPU 1101, ROM 1102, and RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0148] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, and the like; an output section 1107 including displays such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1108 including a hard disk; and a communication section 1109 including a network interface card such as a LAN card or a modem. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. Removable media 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1110 as needed, so that computer programs read therefrom can be installed into the storage section 1108 as needed.

[0149] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1109, and / or installed from a removable medium 1111. When the computer program is executed by the central processing unit (CPU) 1101, the above-mentioned functions defined in the system of the present application are executed.

[0150] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can include, for example, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.

[0151] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0152] The units described in the embodiments of this application may be implemented in software or hardware. The units described may also be provided in a processor. For example, a processor may be described as including a receiving unit, a payable payment status determination unit, and a transaction unit. The names of these units do not, in some cases, limit the units themselves.

[0153] As another aspect, the present application also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently and not be assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device receives a transaction request, determines the requester identifier and the joint activity identifier; generates a joint activity payment order corresponding to the requester identifier and sends it to the requester corresponding to the requester identifier, determines the receivable payment status of the requester; determines whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status, and if not, refunds the receivable payment amount paid by the requester and ends the transaction; if so, determines the target resource corresponding to the joint activity, generates a resource transaction order, deducts virtual funds from the agent account equal to the amount of the resource transaction order in real time, determines the actual payment amount corresponding to the requester, and deducts the actual payment amount from the requester's account at a preset time.

[0154] According to the technical solution of the embodiment of the present application, when multiple requesters request resources from multiple suppliers, the agent can be charged in real time, and the requesters can evenly account for the charges offline, thereby improving the flexibility of resource transactions.

[0155] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A transaction method, characterized in that: include: receiving a transaction request and determining a requester identifier and a joint activity identifier; generating a joint activity payment order corresponding to the requester ID and sending the order to the requester corresponding to the requester ID, and determining the receivable payment status of the requester; Based on the receivable payment status, determining whether to initiate the joint activity corresponding to the joint activity identifier; if not, refunding the receivable payment amount paid by the requesting party and terminating the transaction; if so, determining the target resource corresponding to the joint activity, generating a resource transaction order, deducting virtual funds from the agent's account in real time equal to the amount of the resource transaction order, and determining the actual payment amount corresponding to the requesting party, and then deducting the actual payment amount from the requesting party's account at a preset time; the actual payment amount is the actual payment account, T is the transaction date, and determining the actual payment amount corresponding to the requesting party and then deducting the actual payment amount from the requesting party's account at a preset time includes: on day T+1, counting all resource transaction orders corresponding to the joint activity identifier on day T, offline amortizing the expenses of each requesting party based on the asset ratio of the requesting party bound to the joint activity identifier, generating an actual payment account for each requesting party, integrating the actual payment accounts of each requesting party when the joint activity expires, and deducting the asset balance of the corresponding requesting party in the business system based on the integrated actual payment accounts of each requesting party.

2. The method according to claim 1, characterized in that Before the real-time deduction of the agent's virtual money equal to the amount of the resource transaction order, the method further includes: In response to the initiation of a joint activity, the requesting party whose receivable payment status is paid is determined, and then the corresponding total assets of the joint activity are determined, and the agent is granted the right to handle the total assets of the joint activity, and then virtual money equal to the total assets of the joint activity is added to the agent's account.

3. The method according to claim 1, characterized in that Determining the requester identifier includes: Determining a resource identifier corresponding to the transaction request, and determining a target requester group based on the resource identifier; generating invitation information based on the joint activity identifier; sending the invitation information to the target requesting party group, and receiving feedback information from the target requesting party group on the invitation information; The requester identifier is determined based on the feedback information.

4. The method according to claim 1, wherein Before receiving the transaction request, the method further includes: Receive a joint activity creation request, obtain the joint activity resource identifier, agent identifier, designated invitation requester identifier, activity cycle data, activity limit and recruitment identifier, and then build the corresponding joint activity and generate a joint activity identifier.

5. The method according to claim 1, wherein The determining of the actual payment amount corresponding to the requesting party includes: Obtaining the transaction day activity deduction details corresponding to the deducted agent party account virtual funds; Determine the matching ratio of the receivable and payment amounts of the requesting party participating in the joint activity; Based on the receivable payment amount matching ratio and the transaction day activity deduction details, the shared expenses of the requesting parties participating in the joint activity are determined, and then the actual payment amount corresponding to the requesting parties participating in the joint activity is determined.

6. The method according to claim 1, characterized in that Before generating the joint activity payment order corresponding to the requester identifier and sending it to the requester corresponding to the requester identifier, the method further includes: Determining the number of requesting parties based on the requesting party identifier; In response to determining that the number of requesting parties is greater than two, a process of generating a joint activity payment order is executed.

7. The method according to claim 1, characterized in that The determining whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment status includes: determining the number of paid requesting parties based on the receivable payment status; In response to determining that the number of paid requesting parties is greater than two, an initiation process for a joint activity is performed.

8. The method according to any one of claims 1 to 7, characterized in that After deducting the actual payment amount from the account of the requesting party at a preset time, the method further includes: At the preset time, determine the total amount of actual payment deducted from the requester's account and the total amount of virtual gold deducted from the agent's account, and judge whether the total amount of actual payment and the total amount of virtual gold are equal. If so, no processing will be performed; otherwise, an alarm process will be executed.

9. A transaction device, characterized in that: include: a receiving unit configured to receive a transaction request and determine a requester identifier and a joint activity identifier; a receivable payment status determining unit configured to generate a joint activity payment order corresponding to the requester identifier and send the order to the requester corresponding to the requester identifier, and determine the receivable payment status of the requester; The transaction unit is configured to determine whether to initiate a joint activity corresponding to the joint activity identifier based on the receivable payment status; if not, refund the receivable payment amount paid by the requesting party and terminate the transaction; if yes, determine the target resource corresponding to the joint activity, generate a resource transaction order, deduct virtual funds from the agent's account in real time equal to the amount of the resource transaction order, determine the actual payment amount corresponding to the requesting party, and deduct the actual payment amount from the requesting party's account at a preset time; the actual payment amount is a real-receipt account, where T is a transaction date; determining the actual payment amount corresponding to the requesting party and deducting the actual payment amount from the requesting party's account at a preset time include: on day T+1, counting all resource transaction orders corresponding to the joint activity identifier on day T, offline amortizing the expenses of each requesting party based on the asset ratio of the requesting party bound to the joint activity identifier, generating a real-receipt account for each requesting party; when the joint activity expires, integrating the real-receipt accounts of each requesting party, and deducting the asset balance of the corresponding requesting party in the business system based on the integrated real-receipt accounts of each requesting party.

10. The device according to claim 9, characterized in that The transaction device further includes a virtual money increasing unit configured to: In response to the initiation of a joint activity, the requesting party whose receivable payment status is paid is determined, and then the corresponding total assets of the joint activity are determined, and the agent is granted the right to handle the total assets of the joint activity, and then virtual money equal to the total assets of the joint activity is added to the agent's account.

11. A transaction electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 8.

12. A computer-readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images