CN114493870A

CN114493870A - Transaction method, transaction device, electronic equipment and computer readable medium

Info

Publication number: CN114493870A
Application number: CN202210068117.8A
Authority: CN
Inventors: 李春歌; 樊海龙
Original assignee: Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2022-01-20
Filing date: 2022-01-20
Publication date: 2022-05-13

Abstract

The application discloses a transaction method, a transaction device, electronic equipment and a computer readable medium, which relate to the technical field of computers, and the method comprises the following steps: receiving a transaction request, and determining a requester identifier and a joint activity identifier; generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester; determining whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, performing refund processing on the payment due amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the combined activity, generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and deducting the real payment amount from the account of the requester at the preset time. Therefore, the agent party can be deducted in real time, the requester can share the account in an off-line mode, and the flexibility of resource transaction is improved.

Description

Transaction method, transaction device, electronic equipment and computer readable medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a transaction method, an apparatus, an electronic device, and a computer-readable medium.

Background

In the process of requesting resources by requesters, each requester can purchase a plurality of resources respectively, and for some resources with transaction thresholds, requesters with small transaction amount cannot perform transactions, can only complete one-to-many and many-to-one transactions, are all transactions at one time, have poor flexibility and cannot split transactions as required.

In the process of implementing the present application, the inventor finds that at least the following problems exist in the prior art:

in the process of requesting resources by a requester, transactions cannot be split as required, and the flexibility of resource transactions is poor.

Disclosure of Invention

In view of this, embodiments of the present application provide a transaction method, an apparatus, an electronic device, and a computer-readable medium, which can solve the problems that in the process of requesting a resource by a requester, the transaction cannot be split as needed, and the flexibility of resource transaction is poor.

To achieve the above object, according to an aspect of an embodiment of the present application, there is provided a transaction method including:

receiving a transaction request, and determining a requester identifier and a joint activity identifier;

generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester;

determining whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, performing refund processing on the payment due amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time.

Optionally, before deducting in real time the agent virtual money equal to the amount of the resource trade order, the method further comprises:

and responding to the joint activity starting, determining a request party with a payment state which is due to payment, further determining corresponding joint activity total assets, endowing the agent party with a processing authority for the joint activity total assets, and further adding virtual money equivalent to the joint activity total assets in an account of the agent party.

Optionally, determining the requestor identification comprises:

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 invitation information to a target request party group, and receiving feedback information of the target request party group to the invitation information;

a requestor identification is determined based on the feedback information.

Optionally, prior to receiving the transaction request, the method further comprises:

receiving a joint activity creating request, acquiring joint activity resource identification, agent identification, appointed invitation requester identification, activity cycle data, activity quota and recruitment identification, further constructing corresponding joint activities, and generating joint activity identification.

Optionally, determining the real payment amount corresponding to the requester includes:

acquiring transaction day activity deduction details corresponding to the deducted agent account virtual money;

determining a proportion of the amount of the payment due of the requesters participating in the combined activity;

and determining the shared charge of the requesters participating in the joint activities based on the proportion of the payment amount to be paid and the deduction details of the activities on the transaction day, and further determining the real payment amount corresponding to the requesters participating in the joint activities.

Optionally, before generating and sending the consolidated activity payment order corresponding to the requester identity to the requester corresponding to the requester identity, the method further includes:

determining the number of requesters according to the requester identifications;

in response to determining that the number of requesters is greater than two, performing a generation process for the consolidated activity payment order.

Optionally, determining whether to start the joint activity corresponding to the joint activity identifier based on the payment due status includes:

determining the number of paid requesters according to the receivable payment state;

in response to determining that the number of paid requesters is greater than two, an initiation process of the federated activity is performed.

Optionally, after deducting the real payment amount from the account of the requester at a preset time, the method further comprises:

and determining the total real payment amount of the deducted account of the requesting party and the total virtual money amount of the deducted account of the agent party at preset time, judging whether the total real payment amount is equal to the total virtual money amount, if so, not processing, and otherwise, executing an alarm process.

In addition, the present application also provides a transaction apparatus comprising:

a receiving unit configured to receive a transaction request, determine a requestor identification and a joint activity identification;

the payment due state determining unit is configured to generate a joint activity payment order corresponding to the requester identifier, send the joint activity payment order to the requester corresponding to the requester identifier, and determine the payment due state of the requester;

the transaction unit is configured to determine whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, refund the payment due amount paid by the requester and end the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time.

Optionally, the transaction apparatus further comprises a virtual fund adding unit configured to:

Optionally, the receiving unit is further configured to:

generating invitation information based on the joint activity identifier;

a requestor identification is determined based on the feedback information.

Optionally, the transaction apparatus further comprises a joint activity construction unit configured to:

Optionally, the transaction unit is further configured to:

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

Optionally, the transaction unit is further configured to:

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

In addition, the present application also provides a transaction electronic device, comprising: one or more processors; a storage device for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the transaction method as described above.

In addition, the present application also provides a computer readable medium, on which a computer program is stored, which when executed by a processor implements the transaction method as described above.

One embodiment of the above invention has the following advantages or benefits: the method comprises the steps of determining a requester identifier and a joint activity identifier by receiving a transaction request; generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester; determining whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, performing refund processing on the payment due amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time. Therefore, when multiple requesters request resources of multiple suppliers, the agent can be charged in real time, the requesters share accounts in an off-line mode, and the flexibility of resource transaction is improved.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a further understanding of the application and are not to be construed as limiting the application. Wherein:

fig. 1 is a schematic diagram of a main flow of a transaction method according to a first embodiment of the present application;

FIG. 2 is a schematic diagram of a main flow of a transaction method according to a second embodiment of the present application;

FIG. 3 is an interaction diagram of a transaction method according to an embodiment of the application;

FIG. 4 is a schematic diagram illustrating the structure of a transaction method according to an embodiment of the present application;

FIG. 5 is a schematic flow chart diagram of a transaction method according to a third embodiment of the present application;

FIG. 6 is a schematic diagram of a joint activity creation flow of a trading method according to an embodiment of the present application;

FIG. 7 is a schematic representation of a joint activity transaction flow of a transaction method according to an embodiment of the present application;

FIG. 8 is a schematic flow chart illustrating the execution of a joint activity of a trading method according to an embodiment of the present application;

FIG. 9 is a schematic diagram of the main elements of a transaction device according to an embodiment of the present application;

FIG. 10 is an exemplary system architecture diagram to which embodiments of the present application may be applied;

fig. 11 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present application.

Detailed Description

The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness. According to the technical scheme, the data acquisition, storage, use, processing and the like meet relevant regulations of national laws and regulations.

Fig. 1 is a schematic diagram of a main flow of a transaction method according to a first embodiment of the present application, and as shown in fig. 1, the transaction method includes:

step S101, receiving a transaction request, and determining a requester identifier and a joint activity identifier.

In this embodiment, an execution main body (for example, a server) of the transaction method may receive a transaction request initiated by each requesting party through a wired connection or a wireless connection. It can be understood that the transaction request may be initiated by one requester or multiple requesters, and the number of the initiation requesters corresponding to the transaction request is not specifically limited in the embodiments of the present application. As shown in fig. 4, the requesting party is the resource purchaser. The resource purchaser may include a requestor 1, a requestor 2, a requestor 3, a requestor 4, a requestor 5, and the like. The requester identifier may be a name (chinese character or pinyin) of the requester, a contact information of the requester, and the like, and the specific content and the expression form of the requester identifier are not limited in the present application. The joint activity identifier is a joint activity identifier, such as 1 and 2, corresponding to the requester identifier determined according to the transaction request of the requester, and corresponds to joint activity 1 and joint activity 2 in fig. 4, respectively.

Specifically, determining the requestor identification includes:

and determining a resource identifier corresponding to the transaction request, and determining a target requester group based on the resource identifier. For example, in fig. 4, resources 1, 2, 3, and 4 of the service layer are the resource identifiers. In the resource preparation phase, the executive body creates resource data in the service platform system according to the resource data provided by the resource docking system provided by the supplier, defines a full-platform unique standard code, namely a resource identifier, for each resource, and binds the supplier information to which the resource belongs. The resources are configured on at least one publisher side, the resources are published on the publisher, and basic attribute fields required by the current publisher service are set, wherein the basic attribute fields comprise unit price, preference, supportable time and the like. Publishing a resource on a publisher, such as publishing resource 1 on publisher 1, publishing resource 2 on publisher 2, publishing resource 1 on publisher 3, publishing resource N on publisher N in fig. 4. The embodiment of the application does not specifically limit the resources published by the publisher, and the publisher and the resources do not have a fixed corresponding relationship. For example, as shown in fig. 4, when the executing entity determines that the resource identifiers corresponding to the transaction requests are 1 and N, it may be determined that the target requester group includes requester 1, requester 2, requester 3, requester 4, and requester 5 in fig. 4.

Based on the federated activity identity, invitation information is generated. For example, when the joint activity identifier is 2, based on the joint activity 2 shown in fig. 4, invitation information for participating in the joint activity 2 is generated, where the invitation information may include identifiers of requesters and joint activity identifiers included in the target requester group, and other information such as a publishing resource, agent information, information specifying the requester to invite, activity cycle data including an activity start time, an activity end time, an activity limit, whether to recruit a system, and the like.

And sending invitation information to the target requesting party group, and receiving feedback information of the target requesting party group to the invitation information.

Specifically, feedback information such as whether the target requester group has all clicked the "confirm invited" button, or whether a number (e.g., 1) or letter (yes) characterizing the receipt of the invitation has been returned, etc.

A requestor identification is determined based on the feedback information.

Specifically, when the execution subject determines that the feedback information includes the relevant information indicating "confirm invited", for example, the reply "1" is received, or the reply "yes" is received, the identifier corresponding to the requester who replies indicating "confirm invited" is determined as the requester identifier corresponding to the joint campaign 2.

Specifically, prior to receiving the transaction request, the method further comprises:

For example, the execution agent may perform joint activity creation through the joint activity system, define a unique plan ID, and bind joint activity attributes including multiple publishing resources, agent information, a specified invitation requester, activity cycle data including activity start time, activity end time, activity quota, whether to recruit a system, and the like to the joint activity plan.

And step S102, generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester.

Specifically, before generating and sending the consolidated activity payment order corresponding to the requester identifier to the requester corresponding to the requester identifier, the method further includes: determining the number of requesters according to the requester identifications; in response to determining that the number of requesters is greater than two, performing a generation process for the consolidated activity payment order.

And step S103, determining whether to start the joint activities corresponding to the joint activity identification based on the payment due state.

Specifically, determining whether to start the joint activity corresponding to the joint activity identifier based on the payment due state includes:

The amount due paid by the requester is frozen in the account number requested by the service centre system as shown in figure 5.

And step S104, if not, carrying out refund processing on the payment amount which is paid by the requester and is receivable, and ending the transaction.

And if the number of the paid requesters is less than two, performing refund processing on the paid amount of the requesters.

And step S105, if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the agent account virtual money equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time.

If the number of paid requesters is greater than two, the federated activity is initiated. The processing right of the total assets (the frozen total assets of each requester) of the joint activity 2 of the agent party 2 corresponding to the joint activity 2 shown in fig. 4 is granted, and the virtual money equivalent to the total transaction amount of the joint activity is added to the account of the agent party. Determining target resources corresponding to the combined activity, for example, the resource 1 on the issuer 3 and the resource N on the issuer N in fig. 4, further generating a resource transaction order corresponding to the resource 1 and the resource N, charging in real time to deduct an agent account virtual money equivalent to the amount of the resource transaction order, determining an actual payment amount corresponding to the requester, and further performing off-line shared charging, that is, deducting the actual payment amount from the account of the requester at a preset time.

Specifically, determining the real payment amount corresponding to the requester includes:

acquiring transaction day activity deduction details corresponding to the deducted agent account virtual money; determining an amount due mix for requestors participating in the consolidated activity, such as participant 1: and the participant 2: and 3, the participant: and 4, the participant: the participant 5 is 1:2:3:4: 5. And determining the shared charge of the requesters participating in the joint activities based on the proportion of the payment amount to be paid and the deduction details of the activities on the transaction day, and further determining the real payment amount corresponding to the requesters participating in the joint activities. The transaction day activity deduction details, for example, the deduction corresponding to one activity plan in the combined activity is 15 yuan, and the shared fees of the requesters participating in the combined activity are 1 yuan, 2 yuan, 3 yuan, 4 yuan and 5 yuan based on the charge amount ratio to be paid.

The payment amount due is the amount of the consolidated campaign payment order paid by each requester. The amount of the payment due of each requester may be the same or different, and is specifically determined according to the specific requirement of each requester on the resource, which is not limited in the embodiment of the present application.

Specifically, after deducting the real payment amount from the account of the requester at a preset time, the transaction method further includes:

And when the execution main body determines that the sum of the actual payment amounts of the various deducting requesting parties is not equal to the amount of the transaction day activity deduction detail, indicating that the calculation is possible to cause a problem, and performing alarm processing.

The embodiment determines a requester identifier and a joint activity identifier by receiving a transaction request; generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester; determining whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, performing refund processing on the payment due amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time. Therefore, when multiple requesters request resources of multiple suppliers, the agent can be charged in real time, the requesters share accounts in an off-line mode, and the flexibility of resource transaction is improved.

Fig. 2 is a schematic main flow chart of a transaction method according to a second embodiment of the present application, and as shown in fig. 2, the transaction method includes:

step S201, receiving a transaction request, and determining a requester identifier and a joint activity identifier.

When the executing agent detects that a transaction request sent by a requesting party is received, whether the transaction request is a joint activity recruited by a corresponding system can be detected. In particular, it may be determined whether the joint activities of the system recruitment correspond by determining whether the transaction request includes a system recruitment identifier, such as XTZM.

Illustratively, as shown in FIG. 6, the step of performing the creation of the federated campaign includes: start (start) configuration of an active resource list by an executing agent, configuration of an active invitation requester (which may include requesters with the same resource requirements), configuration of the active attributes: quota, activity cycle, convenience of proxy. Further determining whether the system recruits the target request party and pushing the activity information if the system recruits the target request party; if the combined activity is not the system recruitment, the activity information is pushed to a specified requesting party (for example, the requesting party which sends the transaction request), the specified requesting party actively invites the determined target requesting party to perform the combined activity creation, and the combined activity creation process is ended (end) in response to the successful combined activity creation.

In an example, a requester or a service party performs joint activity creation through a joint activity system, a unique plan ID is defined, and joint activity attributes including a plurality of publishing resources, agent information, a specified invitation requester, activity cycle data including activity start time, activity end time, activity quota, whether system recruitment is required, and the like are bound to an activity plan. And after the creation is completed, the execution main body sends a push joint activity publishing activity reminding message to a specified invitation requesting party. And if the activities need to be recruited by the system, the executive main body analyzes the target requester groups with the same requirements, and then sends a combined activity prompt. The requesters receiving the federated activity alert message may also send the federated activity invitation message to the target group of requesters using the activity invitation function. The target requesting party group with the same requirement can be automatically determined by the service end at the service party side according to the precipitated service data, for example, the target requesting party group can be determined according to historical transaction data of the requesting party, the transaction of the requesting party to the resource represents the preference of the requesting party to the resource, and the target requesting party group of the joint activity can be determined by utilizing the historical transaction data of the requesting party. Therefore, target requesting party groups with the same requirements participate in the joint activities, the transaction probability of the requesting parties to the resources can be mutually promoted, and the resource optimization effect is improved.

Step S202, generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester.

Step S203, determining whether to start the joint activities corresponding to the joint activity identification based on the payment due state.

And step S204, if not, carrying out refund processing on the payment amount which is paid by the requester and is receivable, and ending the transaction.

And S205, if yes, responding to the joint activity starting, determining that the receivable payment state is the paid requester, further determining the corresponding joint activity total asset, giving a processing authority to the joint activity total asset to the agent, and further adding a virtual fund equivalent to the joint activity total asset in the account of the agent.

And (4) starting the joint activity, and if the joint activity plan codes bound agents have the processing right of the total assets (the total assets of all the frozen requesters) of the joint activity, and adding the equivalent virtual money of the total transaction amount of the joint activity in the system account of the agents.

For example, as shown in FIG. 7, the joint activity transaction flow is as follows:

starting (start) a requester to initiate a joint activity transaction, detecting whether more than two bits of requests initiate the transaction by an execution main body, and if not, ending the transaction; if yes, pushing a payment order to the requester, if the requester pays successfully, adding the frozen payment amount to the account of the requester, detecting whether more than two requesters pay successfully before the activity is started, if so, starting the joint activity, adding equivalent virtual money to the agent, and if not, refunding the payment amount and ending the transaction.

For example, a request party sends a transaction request to the joint activity according to the requirement of the request party; the request data carries transaction asset information and joint activity plan identification (joint activity plan ID) of the requester on the joint activity; and checking when the activity requirement period is finished, responding to the condition that at least two requesters initiate combined activity transaction requests, successfully triggering the combined activity, and pushing the requesters to pay orders to all transaction requesters, wherein the orders carry unique codes of the requesters, combined activity plan codes and payment amount. The requester receives the payment order, pays by using the capability provided by the service center system, generates the financial accounts receivable of the requester after successful payment, and stores the accounts receivable in the accounting entry; and (3) increasing the (virtual fund) asset balance of the requester in the service platform system (agent). The requestor is bound to the joint campaign plan code. And after the transaction period of the joint activity is ended, recording the ratio of transaction assets and total assets of the requester in the joint activity, and finally starting according to the start time of the joint activity. And (4) starting the joint activity, and if the joint activity plan codes bound agents have the processing right of the total assets (the total assets of all the frozen requesters) of the joint activity, and adding the equivalent virtual money of the total transaction amount of the joint activity in the system account of the agents.

Step S206, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time.

As shown in FIG. 8, the joint activity execution flow is as follows:

start (start) transaction date (T day) agent G initiates resource transaction A, T day agent G initiates resource transaction B, T day agent GG initiates resource transaction N. And the transaction date is finished and the agent virtual fund is deducted. And deducting the virtual money of the agent party, and recording the deduction details of the combined activity (including the batch of the combined activity plan, the identification of the agent party, the identification of the requester, the activity amount and the like) on the T day. And (4) starting to perform uniform calculation on the requester on the T +1 day, and specifically comprising the following steps of: inquiring the activity deduction details of the T day, deducting the actual payment amount of the requesting party according to the fund ratio of the joint activity requesting party (namely the ratio of the actual payment amount to be paid according to the payment order of the joint activity when the joint activity of each requesting party is just created, such as 1:2:3:4: 5: 1:2:3:4:5), and recording the shared fee; the fee deduction is successful, and the financial real-time data are synchronized; and checking the obtained deduction detail total amount and the actual collection total amount of each deducted request party, and if the obtained deduction detail total amount and the actual collection total amount are not equal, executing an alarm process. And ending the activity (end), integrating the shared cost of each requesting party, and deducting the balance of the account of each requesting party.

In an example, the agent selects target resources from a set of publisher information and standard codes of the resources which can be matched with the joint activity plan codes in a time-sharing and batch mode according to the matching of the requester demand and the resource utilization maximization, generates a resource transaction order, identifies a supplier to which the target resources belong in the order, and then performs settlement processing on the identified resource information of the supplier and a supplier docking system. And after the settlement of each resource transaction order is finished, deducting the balance of the virtual money of the account of the agent side in real time according to the amount of the transaction order. And counting all resource transaction orders in the T day on the T +1 day, sharing the cost of each requester off line according to the asset ratio of the requester bound by the joint activity plan code, generating real income bookkeeping of the requester, and storing the real income bookkeeping in an accounting entry. (should receive-real receive); and when the combined activity is over, integrating all the requesting parties to share the cost in the activity period, and deducting the asset balance of the requesting parties in the service system. T: the date of the transaction.

Fig. 3 is an interaction diagram of a transaction method according to an embodiment of the application. The transaction method of the embodiment of the application is applied to a scene that a plurality of requesters request resources from a plurality of suppliers. The scheme of the embodiment of the present specification can be applied to a combined activity transaction and resource processing scenario, as shown in fig. 3, the transaction method of the embodiment of the present application at least involves the following five subjects: a supplier of resources, which is abbreviated as supplier in this embodiment, may be configured to provide resources, and may be, for example, a main body such as a manufacturer of the resources; the issuer of the resource, which is referred to as an issuer in this embodiment, is a business system for issuing the resource, the resource issued by the issuer may include a resource from a provider and also include other resources that are not from the provider, and the manner in which the issuer acquires the resource may be acquired from the provider or may be acquired in other manners, which is not limited in this embodiment. The joint activity publisher of the resource, referred to as a joint activity publisher in this embodiment for short, is a requester or a proxy that only publishes the joint activity, and is collectively referred to as a joint activity publisher. The joint activity issuing party is a party which combines and issues more than one issuing resource to form a resource issuing set and transacts the resource issuing set with the requesting party. A resource requester, which is referred to as a requester in this embodiment for short, is a party that acquires a resource, needs to use the resource, transacts with a joint activity publisher, and aggregates the resource published by the joint activity publisher; the resource broker, referred to as a broker for short in this embodiment, is a party that handles the transaction orders between the associated activity publisher and the multiple requesters and deals with the resources provided by the supplier with the supplier.

The suppliers can have one, two or more, and each supplier can provide at least one type of resource; the number of the publishers is at least one, and each publisher can publish at least one type of resources of at least one supplier; at least one combined activity publisher can publish a resource publishing set; at least one of the requesters also obtains at least one resource publication set from at least one federated activity publisher. There may be one, two or more agents, each of which may offer to process a trade order for at least one of the combined activities. FIG. 3 illustrates, for purposes of example and convenience, a schematic diagram of multiple suppliers, multiple publishers, multiple federated activity publishers, and multiple requesters and multiple brokers.

In a service scene, a plurality of resource suppliers exist, the resources provided by each supplier have characteristics, and the resources of some high-quality suppliers have a certain threshold; in order to implement optimization processing on resources, an embodiment of the present specification provides a resource processing apparatus, where a main body to which the apparatus is applied may be another main body different from the supplier, the publisher, the joint activity publisher, the broker, and the requester, and this embodiment is referred to as a service party, and the service party may provide a service platform, and all of the above parties may serve as users of the service platform, and the service platform provides resource processing services. By way of example, a business may provide clients to a supplier, a publisher, a federated activity publisher, a broker, and a requestor, respectively, with the supplier, publisher, federated activity publisher, broker, and requestor providing their respective clients to communicate with the business platform.

The target resource in the embodiment of the application may refer to different objects in different application scenarios, for example, the target resource may be a software resource such as a processing thread or a bandwidth resource, a hardware resource such as a memory, a hard disk, or a server, an entity such as a commodity, a personal service resource such as cleaning, running legs, or haircut, or a virtual resource such as an internet advertisement, electronic money, a transaction discount fund. In practice, a supplier generally wants to have more requesters trade the target resources it provides.

Fig. 5 is a schematic main flow chart of a transaction method according to a third embodiment of the present application. The supplier docking system publishes the resource (including the resource identification) to the various business systems. Interacting with the joint activity system, selecting a plurality of resources from each service system, selecting an agent party to create joint activity, and binding with the joint activity. The federated activity system creates a federated activity and issues, pushes federated activity notifications to requesters of the business staging system for pushing to the requesters. The method comprises the steps that a requester initiates a transaction request, a joint activity system checks whether more than two requesters provide the transaction request, if so, a payment order is pushed to each requester, the requesters pay successfully, assets corresponding to account numbers and payment amounts of the requesters are added and frozen, a financial system is called to record the amount of money which the requesters should receive, the joint activity system checks whether more than two requesters pay successfully, and if so, joint activity is started. And the requester and the agent of the platform system in the item service send joint activity starting notifications, and the account number of the agent of the platform system in the item service is added with the virtual money equivalent to the activity payment amount. And (3) initiating resource transaction to each service system by using a virtual fund by an agent of the service center system, purchasing the requested resources from the corresponding supplier (namely the supplier) by each service system, successfully paying the purchased resources by each service system, deducting the virtual fund of the agent (namely the agent) in real time, uniformly distributing the request party for charging in offline manner for T (transaction day) +1 day, and recording the financial real-time income. And (4) when the joint activity is finished, sending a joint activity finishing notice to a requester of the service center system by a proxy of the service center system, integrating the deduction fee by the proxy, and deducting real assets corresponding to all requesters from the account number of the requester, namely deducting the total real assets of the requester.

The three execution stages of the embodiment of the application are divided into the following steps in sequence: a resource preparation phase, a joint activity release phase and a joint activity execution phase. A many-to-many transaction between a requestor and a provider is achieved. By adding the agent party between the requesting party and the supplying party, the uniform resource configuration is realized. The agent real-time fee deduction and the requester offline fee deduction are combined, and a design framework for recording financial data according to activity sharing is realized by adopting a real-time pulling and timing pushing mode.

Fig. 9 is a schematic diagram of the main units of a transaction device according to an embodiment of the application. As shown in fig. 9, the transaction apparatus includes a receiving unit 901, a receivable payment state determining unit 902, and a transaction unit 903.

A receiving unit 901 configured to receive a transaction request, determine a requestor identification and a joint activity identification.

And an accounts receivable payment state determination unit 902 configured to generate and send a joint activity payment order corresponding to the requester identifier to the requester corresponding to the requester identifier, and determine an accounts receivable payment state of the requester.

A transaction unit 903 configured to determine whether to start the joint activity corresponding to the joint activity identifier based on the receivable payment state, and if not, perform refund processing on the receivable payment amount paid by the requester and end the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time.

In some embodiments, the transaction device further comprises a virtual fund adding unit, not shown in fig. 9, configured to: and responding to the joint activity starting, determining a request party with a payment state which is due to payment, further determining corresponding joint activity total assets, endowing the agent party with a processing authority for the joint activity total assets, and further adding virtual money equivalent to the joint activity total assets in an account of the agent party.

In some embodiments, the receiving unit 901 is further configured to: 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 invitation information to a target request party group, and receiving feedback information of the target request party group to the invitation information; a requestor identification is determined based on the feedback information.

In some embodiments, the transaction device further comprises a joint activity construction unit, not shown in fig. 9, configured to: receiving a joint activity creating request, acquiring joint activity resource identification, agent identification, appointed invitation requester identification, activity cycle data, activity quota and recruitment identification, further constructing corresponding joint activities, and generating joint activity identification.

In some embodiments, the transaction unit 903 is further configured to: acquiring transaction day activity deduction details corresponding to the deducted agent account virtual money; determining a proportion of the amount of the payment due of the requesters participating in the combined activity; and determining the shared charge of the requesters participating in the joint activities based on the proportion of the payment amount to be paid and the deduction details of the activities on the transaction day, and further determining the real payment amount corresponding to the requesters participating in the joint activities.

In some embodiments, the accounts receivable state determination unit 902 is further configured to: determining the number of requesters according to the requester identifications; in response to determining that the number of requesters is greater than two, performing a generation process for the consolidated activity payment order.

In some embodiments, the transaction unit 903 is further configured to: determining the number of paid requesters according to the receivable payment state; in response to determining that the number of paid requesters is greater than two, an initiation process of the federated activity is performed.

In some embodiments, the transaction device further comprises an alarm unit, not shown in fig. 9, configured to: and determining the total real payment amount of the deducted account of the requesting party and the total virtual money amount of the deducted account of the agent party at preset time, judging whether the total real payment amount is equal to the total virtual money amount, if so, not processing, and otherwise, executing an alarm process.

It should be noted that, the transaction method and the transaction device of the present application have corresponding relation in the specific implementation content, so the repeated content is not described again.

Fig. 10 shows an exemplary system architecture 1000 to which the transaction method or transaction apparatus of embodiments of the present application may be applied.

As shown in fig. 10, the system architecture 1000 may include

terminal devices

1001, 1002, 1003, a network 1004, and a server 1005. The network 1004 is a medium used to provide communication links between the

terminal devices

1001, 1002, 1003 and the server 1005. Network 1004 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A user may use the

terminal devices

1001, 1002, 1003 to interact with a server 1005 via a network 1004 to receive or transmit messages or the like. The

terminal devices

1001, 1002, 1003 may have installed thereon various messenger client applications such as shopping applications, web browser applications, search applications, instant messenger, mailbox clients, social platform software, etc. (by way of example only).

The

terminal devices

1001, 1002, 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 portable computers, desktop computers, and the like.

The server 1005 may be a server providing various services, such as a background management server (for example only) providing support for tasks submitted by users with the

terminal devices

1001, 1002, 1003. The background management server can receive the transaction request and determine a requester identifier and a joint activity identifier; generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester; determining whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, performing refund processing on the payment due amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time. Therefore, when multiple requesters request resources of multiple suppliers, the agent can be charged in real time, the requesters can share accounts in an off-line manner, and the flexibility of resource transaction is improved.

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 disposed in the server 1005.

It should be understood that the number of terminal devices, networks, and servers in fig. 10 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 6, shown is a block diagram of a computer system 600 suitable for use in implementing a terminal device of an embodiment of the present application. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data necessary for the operation of the computer system 600 are also stored. The CPU601, ROM602, and RAM603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output section 607 including a signal processing section such as a Cathode Ray Tube (CRT), a liquid crystal credit authorization inquiry processor (LCD), and the like, and a speaker and the like; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.

In particular, according to embodiments disclosed herein, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments disclosed herein include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The above-described functions defined in the system of the present application are executed when the computer program is executed by the Central Processing Unit (CPU) 601.

It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may include, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes a receiving unit, a payment due status determining unit, and a transaction unit. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to receive a transaction request, determine a requestor identification and a joint activity identification; generating a joint activity payment order corresponding to the requester identifier, sending the joint activity payment order to the requester corresponding to the requester identifier, and determining the receivable payment state of the requester; determining whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, performing refund processing on the payment due amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the account virtual money of the agent party equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at the preset time.

According to the technical scheme of the embodiment of the application, when multiple requesters request resources of multiple suppliers, the agent can be charged in real time, the requesters share accounts in an off-line mode, and the flexibility of resource transaction is improved.

The above-described embodiments should not be construed as limiting the scope of the present application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method of trading, comprising:

determining whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, performing refund processing on the payment due amount paid by the requester and ending the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the agent account virtual money equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at a preset time.

2. The method of claim 1, wherein prior to the real-time deduction of the agent virtual money equal to the amount of the resource trade order, the method further comprises:

and responding to the joint activity starting, determining a request party with a payment state which is paid, further determining corresponding joint activity total assets, endowing an agent party with a processing authority to the joint activity total assets, and further adding virtual money equivalent to the joint activity total assets in an account of the agent party.

3. The method of claim 1, wherein determining the requestor identification comprises:

generating invitation information based on the joint activity identification;

sending the invitation information to the target request party group, and receiving feedback information of the target request party group to the invitation information;

determining a requestor identification based on the feedback information.

4. The method of claim 1, wherein prior to said receiving a transaction request, said method further comprises:

5. The method of claim 1, wherein the determining the real payment amount for the requesting party comprises:

determining a payable amount proportion of requestors participating in the federated activity;

and determining the shared charge of the requesters participating in the combined activity based on the proportion of the payment amount to be paid and the details of the transaction day activity deduction, and further determining the real payment amount corresponding to the requesters participating in the combined activity.

6. The method of claim 1, wherein prior to the generating and sending a consolidated activity payment order corresponding to the requestor identification, the method further comprises:

in response to determining that the number of requestors is greater than two, performing a generation process for the joint activity payment order.

7. The method of claim 1, wherein the determining whether to initiate the federated activity identifies a corresponding federated activity based on the payable status comprises:

in response to determining that the number of paid requesters is greater than two, performing an initiation process for the federated activity.

8. The method according to any one of claims 1-7, wherein after the deducting the real payment amount from the account of the requester at a preset time, the method further comprises:

9. A transaction apparatus, comprising:

the transaction unit is configured to determine whether to start the joint activity corresponding to the joint activity identification based on the payment due state, and if not, refund the payment due amount paid by the requester and end the transaction; if so, determining the target resource corresponding to the combined activity, further generating a resource transaction order, deducting the agent account virtual money equivalent to the amount of the resource transaction order in real time, determining the real payment amount corresponding to the requester, and further deducting the real payment amount from the account of the requester at a preset time.

10. The apparatus of claim 9, wherein the transaction apparatus further comprises a virtual fund adding unit configured to:

11. A transaction electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-8.

12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-8.