Account dividing method, device and equipment

Abstract

The embodiment of the invention discloses an account division method, device and equipment. According to the scheme, after a server side of a first payment application obtains an account division instruction of a transaction platform for a target transaction order for payment by using the first payment application or a second payment application, payment resources of the target transaction order can be obtained, so that the server side of the first payment application can be utilized; and based on the acquired payment resources of the target transaction order, carrying out account division on the target transaction order paid by using each payment application.

Description

[0001] This application is a divisional application of "A method, apparatus and equipment for revenue sharing (application date: June 22, 2022, application number: 202210713858.7)". Technical Field

[0002] This application relates to the field of electronic transaction technology, and in particular to a method, apparatus and equipment for splitting accounts. Background Technology

[0003] With the continuous advancement of internet technology, e-commerce has developed rapidly. People are increasingly engaging in various commercial activities on trading platforms within the open network environment of the internet, facilitating transactions between consumers and merchants. Currently, trading platforms typically support multiple payment applications, allowing consumers to choose any application to pay for their orders. However, the servers of each payment application can generally only process transaction orders generated using their own application, thus failing to meet the need for unified revenue sharing.

[0004] Therefore, how to uniformly distribute revenue for transaction orders generated using different payment applications has become an urgent technical problem to be solved. Summary of the Invention

[0005] The embodiments of this specification provide a revenue sharing method, apparatus, and device that can uniformly share revenue for transaction orders generated using different payment applications, thereby improving the management convenience when sharing revenue for each transaction order.

[0006] To solve the above-mentioned technical problems, the embodiments in this specification are implemented as follows: This specification provides an embodiment of a revenue-sharing method applied to the server side of a first payment application, including: Obtain the revenue sharing instruction from the transaction platform; the revenue sharing instruction is used to instruct revenue sharing processing for the target transaction order generated at the transaction platform; the target transaction order is a transaction order in which the first participant uses a target payment application to pay the second participant, and the target payment application is either the first payment application or the second payment application; Obtain the payment resources for the target transaction order; In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application.

[0007] This specification provides an embodiment of a revenue-sharing device applied to the server side of a first payment application, comprising: The first acquisition module is used to acquire the revenue sharing instruction from the transaction platform; the revenue sharing instruction is used to instruct the revenue sharing processing for the target transaction order generated at the transaction platform; the target transaction order is a transaction order in which the first participant uses a target payment application to pay the second participant, and the target payment application is either the first payment application or the second payment application; The second acquisition module is used to acquire the payment resources of the target transaction order; The revenue sharing module is used to transfer the payment resources of the target transaction order to the revenue sharing account of the second participant in the first payment application in response to the revenue sharing instruction.

[0008] This specification provides an embodiment of a revenue-sharing device, which is a server-side device for a first payment application, comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Obtain the revenue sharing instruction from the transaction platform; the revenue sharing instruction is used to instruct revenue sharing processing for the target transaction order generated at the transaction platform; the target transaction order is a transaction order in which the first participant uses a target payment application to pay the second participant, and the target payment application is either the first payment application or the second payment application; Obtain the payment resources for the target transaction order; In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application.

[0009] At least one embodiment provided in this specification can achieve the following beneficial effects: The server of the first payment application can obtain the revenue sharing instruction from the transaction platform for a target transaction order. This target transaction order can be a transaction in which a first participant uses the first payment application or a second payment application to pay a second participant. The server of the first payment application can also obtain the payment resources for the target transaction order, and in response to the revenue sharing instruction, transfer these resources to the second participant's revenue sharing account within the first payment application. This unified revenue sharing for transaction orders generated using different payment applications improves the ease of management when sharing revenue across various transaction orders. Furthermore, since the transaction platform only needs to interface with the server of the first payment application for revenue sharing, instead of separately interfaceing with the servers of multiple payment applications, it also helps reduce the platform's setup costs. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram illustrating an application scenario of a revenue-sharing method provided in the embodiments of this specification; Figure 2 A flowchart illustrating a revenue-sharing method provided in an embodiment of this specification; Figure 3 The embodiments provided in this specification correspond to Figure 2 A swimlane flowchart illustrating the revenue sharing method in [the context of the project / organization]. Figure 4 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a revenue-sharing device; Figure 5 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a revenue-sharing device. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of one or more embodiments of this specification.

[0013] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0014] Currently, to improve payment convenience for consumers, various online trading platforms typically support multiple payment channels (e.g., primary payment applications, secondary payment applications, etc.). The server-side of a single payment application channel can usually only process the revenue sharing for transactions generated using that channel, thus failing to achieve unified revenue sharing and causing inconvenience for both the trading platform and merchants in managing revenue sharing. Furthermore, because the trading platform needs to interface with the servers of multiple payment channels separately, this increases the platform's costs and the complexity of its daily operations.

[0015] To address the shortcomings of existing technologies, this solution provides the following embodiments: Figure 1 This is a schematic diagram illustrating an application scenario of a revenue-sharing method provided in the embodiments of this specification.

[0016] like Figure 1 As shown, the first participant can use either the first payment application or the second payment application to make payment for a target transaction order initiated at the transaction platform 101. Subsequently, the transaction platform 101 can generate a settlement instruction for the target transaction order and send the settlement instruction to the server 102 of the first payment application.

[0017] When allocating revenue for a target transaction order, the first payment application server 102 can obtain payment resources from the target financial institution 103 for the first participant's payment of the target transaction order. Alternatively, the server 102 can also obtain payment resources for the target transaction order from the account of the first payment application used by the first participant when making the payment. This allows the server 102 to transfer the obtained payment resources for the target transaction order to the second participant's revenue allocation account within the first payment application. This enables unified revenue allocation for transaction orders generated by different payment applications using a single payment application's server, improving the management convenience for transaction platforms and merchants when allocating revenue for transaction orders generated using multiple payment applications.

[0018] Next, a revenue-sharing method provided in the embodiments of the specification will be described in detail with reference to the accompanying drawings: Figure 2 This is a flowchart illustrating a revenue-sharing method provided in an embodiment of this specification. From a programming perspective, the entity executing this process can be the server-side of the first payment application, or the application program located on the server-side of the first payment application. Figure 2 As shown, the process may include the following steps: Step 202: Obtain the revenue sharing instruction from the transaction platform. The revenue sharing instruction is used to instruct revenue sharing processing for the target transaction order generated at the transaction platform; the target transaction order is a transaction order in which the first participant uses a target payment application to pay the second participant, and the target payment application is either the first payment application or the second payment application.

[0019] In this embodiment, the transaction platform can be an e-commerce platform capable of facilitating transactions between consumers and merchants. In practical applications, the transaction platform can provide an application client for consumers to use, enabling them to initiate transaction orders and make payments through the application client. The transaction platform typically also has an application server for managing transaction order revenue sharing and withdrawals. Therefore, the revenue sharing instruction in step 202 can specifically be an instruction initiated by the application server of the transaction platform.

[0020] In this embodiment of the specification, revenue sharing can broadly refer to the process by which a trading platform transfers the money paid by a user for purchasing goods to a merchant. Specifically, the revenue sharing instruction from the trading platform can be used to instruct revenue sharing processing for a target transaction order generated on the trading platform. The target transaction order can be a transaction order in which a first participant uses a target payment application to pay a second participant. The first participant can be a buyer conducting a transaction on the trading platform, and the second participant can be a seller providing goods on the trading platform. The target payment application can be either the first payment application or the second payment application. Figure 2 The implementing entity of the solution is usually the server-side of the first payment application. Since the second payment application is usually another payment application besides the first payment application, therefore... Figure 2 The entity implementing the middle solution is usually not the server side of the second payment application.

[0021] In practical applications, the revenue sharing instruction may include relevant order information related to the target transaction order, so as to facilitate... Figure 2 The implementing entity of the solution will process subsequent revenue sharing based on the relevant order information of the target transaction order. This relevant order information may include at least: the order number of the target transaction order; in addition, it may include: the identification information of the transaction platform, the transaction amount of the target transaction order, the name of the goods traded in the target transaction order, and the identification information of the payment application used by the buyer.

[0022] Step 204: Obtain payment resources for the target transaction order.

[0023] In the embodiments described in this specification, the payment resources can be monetary resources or points resources that the first participant needs to pay to the second participant when conducting a transaction with the second participant on the trading platform. The specific form of the payment resources is not limited in the embodiments described in this specification.

[0024] It should be noted that the execution order of steps 202 and 204 may differ depending on the payment application used by the first participant to make payment for the target transaction order. For example, when the first participant uses a first payment application to pay for the payment resources of the target transaction order, then... Figure 2To prevent the first participant from misappropriating these payment resources, the implementing entity of the middle solution (i.e., the server of the first payment application) needs to transfer these resources out of the first participant's payment account first. This means it needs to first execute the operation of acquiring the payment resources for the target transaction order, without needing to acquire these resources according to the transaction platform's revenue sharing instructions. However, when the first participant uses the second payment application to pay for the target transaction order's payment resources, it needs to acquire these resources according to the platform's revenue sharing instructions. Therefore, it needs to first execute the operation of acquiring the transaction platform's revenue sharing instructions, and then execute the operation of acquiring the payment resources for the target transaction order.

[0025] Step 206: In response to the splitting instruction, transfer the payment resources of the target transaction order to the splitting account of the second participant at the first payment application.

[0026] In this embodiment, a split account can be pre-created for the second participant in the first payment application to receive payment resources for the target transaction order corresponding to the second participant. Specifically, the server of the first payment application can respond to the split instruction by verifying each target transaction order. If the verification is correct, the payment resources for the target transaction order can be transferred to the second participant's split account, thereby completing the split operation for the payment resources of the target transaction order.

[0027] Figure 2 The method described above utilizes the server-side of the first payment application to uniformly distribute revenue for transaction orders generated using different payment applications, which improves the ease of management when distributing revenue for each transaction order. Furthermore, since the transaction platform only needs to interface with the server-side of the first payment application, instead of separately interfaceing with the servers of multiple payment applications, it also helps reduce the platform's setup costs. based on Figure 2 In addition to the method described in the embodiments of this specification, some specific implementation schemes of the method are also provided, which will be described below.

[0028] If the first participant uses the second payment account of the second payment application to make payment for the target transaction order, the server of the first payment application cannot directly obtain the payment resources for the target transaction order deducted from the second payment account. Therefore, the server of the first payment application needs to obtain the payment resources for the target transaction order from the target financial institution. For ease of understanding, this will be explained.

[0029] Specifically, if the target transaction order is a transaction order in which the first participant uses the second payment account of the second payment application to make payment, then step 204: obtaining the payment resources for the target transaction order may include: Send a first resource transfer instruction to the target financial institution; the first resource transfer instruction is used to instruct the transfer of a specified amount of payment resources from the target financial institution.

[0030] The system receives a specified amount of payment resources from the target financial institution; the specified amount of payment resources includes second payment resources paid by the first participant using the second payment account for the target transaction order; the second payment resources are resources obtained by the target financial institution from the server of the second payment application.

[0031] Correspondingly, step 206: In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application, which may specifically include: The second payment resource from the specified amount of payment resources is transferred to the second participant's sub-account.

[0032] In this embodiment, the service provider of the transaction platform can pre-agree with the service provider of the second payment application and the service provider of the target financial institution that, after the first participant completes payment for the target transaction order on the target transaction platform using the second payment account of the second payment application, the server of the second payment application needs to transfer the second payment resources for the target transaction order payment in the second payment account to the target financial institution for safekeeping within a specified time period. The target financial institution can be a bank, and the specified time period can be one day.

[0033] The transaction platform's service provider can also pre-arrange with the service providers of the first payment application and the target financial institution, enabling the target financial institution to respond to the first resource transfer instruction sent by the first payment application's server by transferring a specified amount of payment resources held by it to the first payment application's server. This allows the first payment application's server to obtain the second payment resources for the target transaction order from the second payment account through the target financial institution, thereby completing the revenue sharing. The specified amount of payment resources is determined by the transaction platform and can include payment resources from multiple transaction orders, thus improving resource transfer efficiency.

[0034] In the embodiments described in this specification, in order to ensure fund security, the server of the first payment application usually needs to obtain payment resources from the target financial institution according to the instructions of the transaction platform.

[0035] Based on this, before sending the first resource transfer instruction to the target financial institution, the process may further include: The system receives a second resource transfer instruction sent by the transaction platform; the second resource transfer instruction instructs the system to acquire the specified amount of payment resources from the target financial institution. The first resource transfer instruction is generated after receiving the second resource transfer instruction.

[0036] In the embodiments described in this specification, the second resource transfer instruction sent by the trading platform and the revenue sharing instruction sent by the trading platform can be the same instruction or different instructions, without specific limitations. For example, when the second resource transfer instruction and the revenue sharing instruction are different instructions, the second resource transfer instruction only needs to carry the quantity information of the payment resources to be transferred (i.e., the specified data, for example, 100,000 yuan), without carrying the relevant information of each target transaction order corresponding to the payment resources to be transferred, thereby simplifying the resource transfer operation and process. Of course, the second resource transfer instruction and the revenue sharing instruction can also be the same instruction. In this case, the revenue sharing instruction can also carry the quantity information of the payment resources to be transferred, thereby simplifying the interaction process between the trading platform and the server of the first payment application.

[0037] In the embodiments described in this specification, both the target financial institution and the first payment application can set up corresponding fund custody accounts to manage the payment resources of the target transaction orders to be split, thereby improving the security and convenience of resource management.

[0038] Based on this, receiving the specified amount of payment resources sent by the target financial institution may specifically include: Using the first fund custody account at the first payment application, a specified amount of payment resources are received from the second fund custody account at the target financial institution; the second fund custody account is used to store the resources obtained by the target financial institution from the server of the second payment application.

[0039] Correspondingly, transferring the second payment resource from the specified amount of payment resources to the second participant's sub-account may specifically include: The second payment resources held in the first escrow account are transferred to the second participant's sub-account.

[0040] In the embodiments described in this specification, the revenue sharing instruction may be sent by the transaction platform to the server of the first payment application through an interface call, instructing the server of the first payment application to share the payment resources of the target transaction order obtained from the target financial institution.

[0041] In practical applications, there are various ways to generate a revenue sharing instruction. For example, the instruction can be generated by the transaction platform through a call to the first interface of the first payment application's server. This instruction can directly direct the transfer of payment resources corresponding to the target transaction order from the second escrow account of the target financial institution to the revenue sharing account of the second participant in the first payment application, which is convenient and fast. It is worth noting that after receiving the revenue sharing instruction, the server of the first payment application still needs to receive resources from the second escrow account using the first escrow account and then transfer the resources to the second participant's revenue sharing account using the first escrow account to complete the revenue sharing.

[0042] Alternatively, the revenue sharing instruction can be generated by the transaction platform through calling the second and third interfaces on the server side of the first payment application. Specifically, by calling the second interface, the transaction platform can generate an instruction to transfer the payment resources corresponding to the target transaction order from the second escrow account of the target financial institution to the first escrow account of the first payment application. Subsequently, the transaction platform can continue to call the third interface to generate an instruction to transfer the payment resources corresponding to the target transaction order from the first escrow account of the first payment application to the revenue sharing account of the second participant in the first payment application. Thus, multiple instructions can constitute a revenue sharing instruction, offering good flexibility. The instruction generated by the transaction platform through calling the second interface can be the same instruction as the aforementioned second resource transfer instruction.

[0043] In this embodiment, the first escrow account can be a escrow account registered by the trading platform with the first payment application. The second escrow account is a escrow account registered by the trading platform with the target financial institution. The server of the first payment application receives resources transferred from the second escrow account using the first escrow account to obtain payment resources for the target transaction order paid using the payment account of the second payment application. Furthermore, this payment resource is transferred from the first escrow account to the merchant's sub-account in the first payment application. This achieves the function of using a single payment application's server to perform the same sub-account for transaction orders generated using different payment applications. This avoids the complexity of separate sub-accounts using multiple payment application servers and improves the convenience of sub-account management for the trading platform.

[0044] In the embodiments described in this specification, if the first participant uses the first payment account of the first payment application to make payment for the target transaction order, the server of the first payment application can directly obtain the payment resources for the target transaction order deducted from the first payment account, thus eliminating the need to obtain the payment resources for the target transaction order from the target financial institution. This will be explained for ease of understanding.

[0045] Specifically, if the target transaction order is a transaction order in which the first participant uses the first payment account of the first payment application to make payment, then step 204: obtaining the payment resources for the target transaction order may include: The first payment resources paid by the first participant using the first payment account for the target transaction order are transferred from the first payment account to the first escrow account of the first payment application.

[0046] Correspondingly, step 206: In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application, which may specifically include: The first payment resources held in the first escrow account are transferred to the second participant's sub-account.

[0047] In the embodiments described in this specification, when the first participant makes a payment through the first payment application, the server of the first payment application typically deducts the first payment resources for the target transaction order from the first participant's first payment account after the first participant successfully completes the payment, to prevent the first participant from misappropriating the first payment resources. The first payment resources deducted from the first payment account are sent to the transaction platform for management in the first fund custody account of the first payment application. Subsequently, after receiving the revenue sharing instruction for the target transaction order, the server of the first payment application can transfer the first payment resources in the first fund custody account to the revenue sharing account registered by the second participant (e.g., a merchant) with the first payment application to complete the revenue sharing for the target transaction order.

[0048] In this embodiment of the specification, the trading platform may launch promotional activities from time to time to increase transaction volume and enhance its brand awareness. For example, it may offer discounts or price reductions on specific products from merchants for a specific period. Since the promotional activities are initiated by the trading platform, the discounts offered on specific products must be compensated to the merchants by the trading platform. Therefore, when distributing revenue for target transaction orders, it may be necessary to obtain a portion of the payment resources paid by the trading platform and allocate it to the revenue-sharing account of the second participating party.

[0049] Based on this, step 204: obtaining the payment resources for the target transaction order may specifically include: If the transaction platform is required to pay the third payment resources to the second participant for the target transaction order according to the revenue sharing instruction, then the third payment resources in the transaction platform's third payment account at the first payment application will be transferred to the first fund custody account.

[0050] Correspondingly, step 206: In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application, which may specifically include: The third payment resources held in the first escrow account are transferred to the second participant's sub-account.

[0051] In the embodiments of this specification, the third payment account can be a payment account registered by the transaction platform with the first payment application. The transaction platform can store a portion of the payment resources in the third payment account in advance and make an agreement with the server of the first payment application in advance to allow the server of the first payment application to deduct a specified amount of payment resources (e.g., third payment resources) from the third payment account according to actual needs when distributing the revenue, and allocate it to the revenue distribution account of the second participant to complete the revenue distribution.

[0052] In the embodiments described in this specification, the third payment resource can be the resource that the trading platform needs to pay to the second participant for the target transaction order initiated by the first participant. In practical applications, the transaction platform's settlement instruction can also carry relationship information of the third payment resource corresponding to the target transaction order. This settlement instruction can also be used to instruct the deduction of the third payment resource from the third payment account and its transfer to the second participant's settlement account.

[0053] To facilitate understanding, an example is provided regarding the revenue sharing process related to third-party payment resources. For instance, suppose the target transaction order is an order where the first participant purchases a piece of clothing from the second participant. For this target transaction order, the first participant needs to pay 150 yuan, and the transaction platform needs to pay 50 yuan. The 50 yuan payable by the transaction platform is the third-party payment resource. When the transaction platform needs to share revenue for the target transaction order, its revenue sharing instruction should include information indicating that 50 yuan should be transferred from the third-party payment account as part of the target transaction order's payment resource. This allows the server of the first payment application, upon receiving the revenue sharing instruction, to transfer the 50 yuan from the third-party payment account to the first escrow account, and then transfer the 50 yuan from the first escrow account to the second participant's revenue sharing account, ensuring the accuracy of the revenue sharing.

[0054] In the embodiments described in this specification, during the daily process of online shopping, buyers may return goods after purchasing them from merchants due to dissatisfaction with the quality of the goods. In this case, if the payment resources for the transaction have already been transferred to the merchant's revenue sharing account, then these payment resources in the merchant's revenue sharing account must be refunded to the buyer and / or the transaction platform.

[0055] Based on this, after transferring the payment resources for the target transaction order to the second participant's revenue sharing account at the first payment application, it may also include: Obtain the refund instruction from the trading platform for the target transaction order.

[0056] In response to the refund instruction, the initial transfer account for the payment resources of the target transaction order is determined; the initial transfer account includes at least one of the first payment account, the second payment account, and the third payment account.

[0057] The payment resources for the target transaction order in the split account are transferred to the initial transfer-out account.

[0058] In the embodiments described in this specification, the refund instruction can be generated by the trading platform after a full or partial refund of the target transaction order, and is used to instruct the return of all or part of the payment resources corresponding to the target transaction order. For example, After the first participant (buyer) applies for a return and refund for the target transaction order, the transaction platform can issue a refund instruction to the server of the first payment application. The server of the first payment application can determine the source information of the payment resources for the target transaction order, and then, based on the source information of the payment resources, return the funds to the initial transfer account of the payment resources according to the resource transmission link.

[0059] In the embodiments of this specification, the payment resources of the target transaction order may include at least one of a first payment resource, a second payment resource, and a third payment resource. The source information of the first payment resource may be a registered account at the first payment application. Based on the source information of the first payment resource and the relevant order information of the target transaction order, it can be further determined that the initial transfer-out account of the first payment resource is the first payment account at the first payment application, thereby enabling the server of the first payment application to transfer the first payment resource in the second participant's sub-account to the first payment account.

[0060] The source information of the second payment resource can also be a registered account of the second payment application or a target financial institution. Based on the source information of the second payment resource, it can be further determined that the initial transfer account of the second payment resource is the second payment account of the second payment application or the second fund custody account of the target financial institution, so that the server of the first payment application can transfer the second payment resource in the second participant's sub-account to the second payment account through the target financial institution.

[0061] The source information of the third payment resource can be the registered account of the transaction platform in the first payment application. Based on the source information of the third payment resource and the relevant order information of the target transaction order, it can be further determined that the initial transfer account of the third payment resource is the third payment account of the transaction platform, so that the server of the first payment application can transfer the third payment resource in the second participant's account to the third payment account.

[0062] For example, if a buyer purchases clothing on a trading platform that was originally priced at 200 yuan but is now 150 yuan during a promotion, the buyer can pay the merchant 150 yuan, and the trading platform can pay the merchant 50 yuan. If the buyer is dissatisfied with the clothing after receiving it and initiates a return request with the trading platform, the platform can send a refund instruction to the First Payment app's server upon receiving the request. Based on this instruction, the First Payment app's server can then transfer the 200 yuan from the merchant's account on the First Payment app to the First Funds escrow account.

[0063] If a buyer pays 150 yuan using their first payment account within the first payment application when purchasing clothing, the 150 yuan in the first escrow account can be refunded to the buyer's first payment account within the first payment application. If the buyer pays 150 yuan using their second payment account within the second payment application, the 150 yuan in the first escrow account can be refunded to the target financial institution's second escrow account. The target financial institution's server will then refund the 150 yuan in the second escrow account to the buyer's second payment account within the second payment application. Additionally, the first payment application's server can also refund 50 yuan from the first escrow account to the transaction platform's third payment account within the first payment application. This completes the refund process for the transaction.

[0064] In the embodiments described in this specification, when it is necessary to process a refund for a target transaction order, the payment resources of the target transaction order received in the second participant's account can be refunded to the first payment account, the second payment account, or the third payment account through the server of the first payment application. This improves the convenience of refund management for both the transaction platform and merchants.

[0065] In the embodiments described in this specification, the merchants on the transaction platform (i.e., the second participant) need to apply for and register a revenue-sharing account with the server of the first payment application in advance, so that they can use the revenue-sharing account to receive payment resources for their related transaction orders during the revenue-sharing process. The revenue-sharing account is usually an account that the second participant does not have management authority over account payment resources.

[0066] Based on this, before transferring the payment resources for the target transaction order to the second participant's sub-account at the first payment application, the process may further include: Obtain the account creation request sent by the trading platform for the second participant.

[0067] In response to the split account creation request, a split account for the second participant in the first payment application is generated.

[0068] In this embodiment, the second participant can submit an application to the transaction platform to register a revenue-sharing account with the first payment application. In practical applications, the second participant can submit its business license and other registration information to the transaction platform. The transaction platform can then, after approving the merchant's registration information, initiate a revenue-sharing account creation request for the second participant to the server of the first payment application, allowing the server of the first payment application to generate the second participant's revenue-sharing account. Alternatively, the transaction platform can include the merchant's registration information in the revenue-sharing account creation request, allowing the server of the first payment application to register a revenue-sharing account for the merchant after approving the registration information; no specific limitation is made in this regard.

[0069] In the embodiments described in this specification, a single second participant may have multiple revenue-sharing accounts. For example, if a second participant operates multiple online stores on a transaction platform, it can register a revenue-sharing account for each online store. Subsequently, the second participant can specify the revenue-sharing account required for revenue sharing of transaction orders generated by each online store. For example, the second participant can use the same revenue-sharing account to receive payment resources for transaction orders generated by multiple online stores, or it can use a single revenue-sharing account to receive payment resources for transaction orders generated by a single online store; no specific limitation is made in this regard. However, the server of the first payment application can determine the revenue-sharing account required to receive payment resources for each target transaction order based on the relevant order information of the target transaction order, in order to ensure the second participant's willingness to share revenue.

[0070] In the embodiments described in this specification, since the payment resources for the target transaction order can be transferred to the second participant's account after the first participant completes the payment for the target transaction order, but the first participant may subsequently request a full or partial refund for the target transaction order, in order to protect the rights and interests of the first participant, the second participant is prevented from obtaining management rights over the payment resources in its account. This allows the server of the first payment application to return the payment resources in the account to the first participant after the first participant applies for a refund for the target transaction order, thereby helping to protect the rights and interests of the first participant.

[0071] In the embodiments described in this specification, criminals may use online sales to commit fraud and illegal activities. Therefore, in accordance with national regulations, the server of the first payment application needs to conduct risk assessments on the target transaction orders when allocating revenue.

[0072] Based on this, before transferring the payment resources of the target transaction order to the second participant's sub-account at the first payment application, it may further include: Obtain the order information of the target transaction order from the trading platform.

[0073] Risk identification processing is performed based on the order information of the target transaction order to obtain the risk identification result for the target transaction order.

[0074] Step 206: Transferring the payment resources of the target transaction order to the second participant's sub-account in the first payment application may specifically include: If the risk identification result meets the preset revenue sharing conditions, the payment resources of the target transaction order will be transferred to the revenue sharing account of the second participant in the first payment application.

[0075] Furthermore, if the risk identification result does not meet the preset revenue sharing conditions, a revenue sharing prohibition prompt message can be generated; the revenue sharing prohibition prompt message is used to indicate that revenue sharing processing is prohibited for the target transaction order based on the risk identification result of the target transaction order.

[0076] In the embodiments described in this specification, after receiving the revenue sharing instruction for the target transaction order from the transaction platform, the server of the first payment application will conduct a risk assessment for each target transaction order. Specifically, the server of the first payment application can obtain more detailed order details of the target transaction order from the transaction platform based on the order number of the target transaction order carried in the revenue sharing instruction, such as the registration information of the first and second participants, the quantity of goods in the order transaction, the time when the order transaction occurred, the reserved telephone numbers and delivery addresses of the first and second participants, etc.

[0077] Subsequently, the server-side of the First Payment application can perform risk identification processing based on the order details of the target transaction order. Furthermore, if the target transaction order is paid using the First Payment account within the First Payment application, the First Payment application will also generate a corresponding payment order, allowing the server-side of the First Payment application to perform risk identification processing based on the order details of the corresponding payment order.

[0078] In practical applications, the server-side of the first payment application can utilize existing risk identification rules or models to perform risk identification processing on target transaction orders to obtain the corresponding risk identification result. The risk identification result for the target transaction order can be in the form of a risk score. A preset revenue sharing condition could be that if the risk score is less than a preset threshold, revenue sharing is allowed; otherwise, it is prohibited. For example, a risk score above 70 typically indicates a high probability of transaction risk (such as money laundering or fraud), thus revenue sharing can be prohibited. In this case, if the risk identification result for the target transaction order is 65, it means that the risk identification result meets the preset revenue sharing condition, and the payment resources for the target transaction order in the first fund custody account of the first payment application can be transferred to the second participant's revenue sharing account in the first payment application.

[0079] In the embodiments of this specification, the payment resources of the target transaction order are transferred to the second participant's account at the first payment application only after the risk identification result corresponding to the target transaction order meets the preset revenue sharing conditions, so as to complete the revenue sharing. This helps to reduce the possibility of the second participant engaging in illegal and criminal activities through the transaction platform, thereby ensuring the legality and compliance of the revenue sharing method.

[0080] In the embodiments described in this specification, since the second participant does not have management authority over the payment resources in the sub-account, it is unable to control these payment resources, and thus there is a need to withdraw the payment resources in the sub-account.

[0081] Based on this, after transferring the payment resources of the target transaction order to the second participant's sub-account at the first payment application, it may further include: Obtain a withdrawal instruction from the trading platform; the withdrawal instruction is used to instruct the transfer of the target payment resources in the split account to the fourth payment account of the second participant, the fourth payment account being an account of the second participant with management authority over account payment resources.

[0082] In response to the withdrawal instruction, the target payment resources in the split account are transferred to the fourth payment account of the second participant.

[0083] In the embodiments described in this specification, the transaction platform can send a withdrawal instruction to the server of the first payment application. The withdrawal instruction usually needs to specify the amount of resources to be withdrawn, but it does not need to specify the transaction order information corresponding to the resources to be withdrawn, which helps to simplify the withdrawal operation.

[0084] After receiving a withdrawal instruction, the server of the first payment application can transfer the target payment resources indicated in the withdrawal instruction from the second participant's sub-account to a fourth payment account of the second participant with corresponding resource management authority to complete the withdrawal. The fourth payment account can be either a payment account registered by the second participant with the first payment application or a payment account with another financial institution; there is no specific limitation on this.

[0085] In the embodiments of this specification, by transferring payment resources from the second participant's sub-account (the second participant does not have the corresponding resource management authority) to the fourth payment account (the second participant has the corresponding resource management authority), the withdrawal function of the sub-accounted payment resources can be realized, which is convenient and fast.

[0086] Figure 3 The embodiments provided in this specification correspond to Figure 2 A swimlane flowchart illustrating the revenue-sharing method in [the context of the project]. For example... Figure 3 As shown, this revenue sharing process can involve various entities such as transaction platforms, the server-side of the first payment application, and financial institutions.

[0087] During the revenue sharing phase, the transaction platform can send a revenue sharing instruction for the target transaction order to the server of the first payment application. The target transaction order can be a transaction order in which the first participant uses the target payment application to make a payment to the second participant, wherein the target payment application can be either the first payment application or the second payment application.

[0088] In response to the revenue sharing instruction, the server of the first payment application can obtain the payment resources for the target transaction order. In practical applications, the payment resources for the target transaction order may include at least one of the first payment resources, the second payment resources, and the third payment resources.

[0089] The first payment resource can be the resource paid by the first participant using the first payment account of the first payment application for the target transaction order. The server of the first payment application can usually transfer the first payment resource in the first payment account to the first fund custody account of the first payment application after the target transaction order is paid, so that the server of the first payment application can obtain the first payment resource without waiting for the transaction platform to issue a settlement instruction before transferring the first payment resource to the first fund custody account.

[0090] The second payment resource can be the resources paid by the first participant using a second payment account in a second payment application for the target transaction order. Regarding the second payment resource, the server of the first payment application can send a first resource transfer instruction to a financial institution to transfer a specified quantity of payment resources. After receiving the first resource transfer instruction from the first payment application, the target financial institution can transfer the specified quantity of payment resources from its second escrow account to the first escrow account of the first payment application. This specified quantity of payment resources may include the second payment resources paid by the first participant using the second payment account in the second payment application for the target transaction order. This allows the server of the first payment application to access the second payment resource.

[0091] The third payment resource can be the resource that the trading platform needs to use to pay for a target transaction order through the third payment account of the first payment application. After receiving the settlement instruction, the server of the first payment application can transfer the third payment resource in the third payment account of the trading platform in the first payment application to the first fund custody account of the first application, according to the transaction rules of the actual transaction order, so that the server of the first payment application can obtain the third payment resource.

[0092] Subsequently, the server-side of the first payment application can obtain the order information of the target transaction order from the transaction platform and perform risk identification on the order information to obtain the risk identification result for the target transaction order. If the risk identification result meets the preset revenue sharing conditions, the server-side of the first payment application can transfer the payment resources of the target transaction order to the revenue sharing account of the second participant in the first payment application, thereby completing the revenue sharing. If the risk identification result does not meet the revenue sharing conditions, the server-side of the first payment application will not perform the revenue sharing operation to prevent the transfer of the payment resources of the target transaction order to the revenue sharing account of the second participant in the first payment application.

[0093] During the refund phase, the transaction platform can send a refund instruction for the target transaction order to the server of the first payment application. Upon receiving this instruction, the server of the first payment application can determine the initial transfer account for the payment resources of the target transaction order, such as the first payment account in the first payment application, the second payment account in the second payment application, or the third payment account in the first payment application. The payment resources for the target transaction order will then be refunded to the original initial transfer account.

[0094] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods. Figure 4 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a revenue-sharing device. For example... Figure 4As shown, the device may include: The first acquisition module 402 is used to acquire the revenue sharing instruction of the transaction platform; the revenue sharing instruction is used to instruct the revenue sharing processing for the target transaction order generated at the transaction platform; the target transaction order is a transaction order in which the first participant uses a target payment application to pay the second participant, and the target payment application is either the first payment application or the second payment application; The second acquisition module 404 is used to acquire the payment resources of the target transaction order; The revenue sharing module 406 is used to transfer the payment resources of the target transaction order to the revenue sharing account of the second participant in the first payment application in response to the revenue sharing instruction.

[0095] based on Figure 4 The embodiments of this specification also provide some specific implementations of the device, which will be described below.

[0096] Optionally, the target transaction order may be a transaction order in which the first participant makes payment using the second payment account of the second payment application.

[0097] Correspondingly, the second acquisition module 404 includes: An instruction sending unit is configured to send a first resource transfer instruction to a target financial institution; the first resource transfer instruction is configured to instruct the transfer of a specified amount of payment resources from the target financial institution; A resource receiving unit is configured to receive the specified number of payment resources sent by the target financial institution; the specified number of payment resources includes second payment resources paid by the first participant using the second payment account for the target transaction order; the second payment resources are resources obtained by the target financial institution from the server of the second payment application; The revenue sharing module 406 may specifically include: The first revenue sharing unit is used to transfer the second payment resource from the specified amount of payment resources to the revenue sharing account of the second participant.

[0098] Correspondingly, the resource receiving unit can specifically be used for: Using the first fund custody account at the first payment application, a specified amount of payment resources are received from the second fund custody account at the target financial institution; the second fund custody account is used to store the resources obtained by the target financial institution from the server of the second payment application; The first revenue-sharing unit can be specifically used for: The second payment resources held in the first escrow account are transferred to the second participant's sub-account.

[0099] Optional, Figure 4 The apparatus described herein may further include: The third acquisition module is used to acquire the second resource transfer instruction sent by the transaction platform; the second resource transfer instruction is used to instruct the acquisition of the specified amount of payment resources from the target financial institution.

[0100] Optionally, the target transaction order may be a transaction order in which the first participant makes payment using the first payment account of the first payment application.

[0101] Correspondingly, the second acquisition module 404 may include: The first resource transfer unit is used to transfer the first payment resources paid by the first participant using the first payment account for the target transaction order from the first payment account to the first fund custody account of the first payment application.

[0102] The revenue sharing module 406 may specifically include: The second revenue sharing unit is used to transfer the first payment resources in the first fund custody account to the revenue sharing account of the second participant.

[0103] Optionally, the second acquisition module 404 may further include: The second resource transfer unit is used to transfer the third payment resources in the third payment account of the trading platform at the first payment application to the first fund custody account if it is determined according to the revenue sharing instruction that the trading platform needs to pay the third payment resources to the second participant for the target transaction order.

[0104] The revenue sharing module 406 may further include: The third revenue-sharing unit is used to transfer the third payment resources in the first fund custody account to the revenue-sharing account of the second participant.

[0105] Optional, Figure 4 The apparatus described herein may further include: The fourth acquisition module is used to acquire the refund instruction for the target transaction order from the transaction platform.

[0106] The account determination module is used to determine the initial transfer account of the payment resources of the target transaction order in response to the refund instruction; the initial transfer account includes at least one of the first payment account, the second payment account and the third payment account.

[0107] The reimbursement module is used to transfer the payment resources of the target transaction order in the reimbursement account to the initial transfer-out account.

[0108] Optional, Figure 4 The apparatus described herein may further include: The fifth acquisition module is used to acquire the account creation request for the second participant sent by the trading platform.

[0109] The revenue sharing account generation module is used to generate the revenue sharing account of the second participant in the first payment application in response to the revenue sharing account creation request.

[0110] Optional, Figure 4 The apparatus described herein may further include: The sixth acquisition module is used to acquire the order information of the target transaction order from the transaction platform.

[0111] The risk identification module is used to perform risk identification processing based on the order information of the target transaction order, and obtain the risk identification result for the target transaction order.

[0112] Correspondingly, the revenue sharing module 406 can be used for: If the risk identification result meets the preset revenue sharing conditions, the payment resources of the target transaction order will be transferred to the revenue sharing account of the second participant in the first payment application.

[0113] Optional, Figure 4 The apparatus described herein may further include: The "prohibit revenue sharing" module is used to generate a "prohibit revenue sharing" prompt message if the risk identification result does not meet the preset revenue sharing conditions. The "prohibit revenue sharing" prompt message is used to indicate that revenue sharing processing is prohibited for the target transaction order based on the risk identification result of the target transaction order.

[0114] Optional, Figure 4 The apparatus described herein may further include: The seventh acquisition module is used to acquire the withdrawal instruction from the trading platform; the withdrawal instruction is used to instruct the transfer of the target payment resources in the sub-account to the fourth payment account of the second participant, the fourth payment account being an account of the second participant with management authority over account payment resources.

[0115] The withdrawal module is used to transfer the target payment resources in the split account to the fourth payment account of the second participant in response to the withdrawal instruction.

[0116] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0117] Figure 5 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a revenue-sharing device. For example... Figure 5 As shown, device 500 may include: At least one processor 510; and, Memory 530 communicatively connected to the at least one processor; wherein, The memory 530 stores instructions 520 that can be executed by the at least one processor 510, the instructions being executed by the at least one processor 510 to enable the at least one processor 510 to: Obtain a revenue sharing instruction from the trading platform; the revenue sharing instruction is used to instruct revenue sharing processing for a target transaction order generated at the trading platform; the target transaction order is a transaction order in which a first participant uses a target payment application to pay a second participant, and the target payment application is either the first payment application or the second payment application.

[0118] Obtain the payment resources for the target transaction order.

[0119] In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application.

[0120] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, for... Figure 5 As the device shown is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0121] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0122] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0123] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0124] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0125] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0126] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0127] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0128] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0129] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0130] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0131] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0132] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0133] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0134] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0135] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A revenue-sharing method, applied to the server side of a first payment application, comprising: Obtain the splitting instructions used for splitting the revenue for the target transaction order; The target transaction order is a transaction order in which the first participant uses a target payment application to make a payment to the second participant. The target payment application is either the first payment application or the second payment application. Obtain the payment resources for the target transaction order; In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application.

2. The method as described in claim 1, wherein if the target transaction order is a transaction order in which the first participant makes payment using the second payment account of the second payment application, then obtaining the payment resources of the target transaction order specifically includes: Send the first resource transfer instruction to the target financial institution; The first resource transfer instruction is used to instruct the transfer of a specified amount of payment resources from the target financial institution; The system receives a specified amount of payment resources from the target financial institution; the specified amount of payment resources includes second payment resources paid by the first participant using the second payment account for the target transaction order; the second payment resources are resources obtained by the target financial institution from the server of the second payment application. The step of transferring the payment resources of the target transaction order to the second participant's sub-account at the first payment application specifically includes: The second payment resource from the specified amount of payment resources is transferred to the second participant's sub-account.

3. The method as described in claim 2, wherein receiving the specified amount of payment resources sent by the target financial institution specifically includes: Using the first fund custody account at the first payment application, a specified amount of payment resources are received from the second fund custody account at the target financial institution; the second fund custody account is used to store the resources obtained by the target financial institution from the server of the second payment application; The step of transferring the second payment resource from the specified amount of payment resources to the second participant's sub-account specifically includes: The second payment resources held in the first escrow account are transferred to the second participant's sub-account.

4. The method as described in claim 3, wherein the revenue sharing instruction is a revenue sharing instruction of the trading platform, and the revenue sharing instruction is used to instruct revenue sharing processing for the target transaction order generated at the trading platform; Before sending the first resource transfer instruction to the target financial institution, the method further includes: Obtain the second resource transfer instruction sent by the trading platform; The second resource transfer instruction is used to instruct the acquisition of the specified amount of payment resources from the target financial institution.

5. The method as described in claim 4, wherein the second resource transfer instruction and the revenue sharing instruction are different instructions; the second resource transfer instruction carries quantity information of the payment resources to be transferred, and the quantity information represents the specified quantity; Alternatively, the second resource transfer instruction and the revenue sharing instruction are the same instruction; the revenue sharing instruction carries information about the quantity of payment resources to be transferred.

6. The method as described in claim 1, wherein if the target transaction order is a transaction order in which the first participant makes payment using the first payment account of the first payment application, then obtaining the payment resources of the target transaction order specifically includes: The first payment resources paid by the first participant using the first payment account for the target transaction order are transferred from the first payment account to the first fund custody account of the first payment application. The step of transferring the payment resources of the target transaction order to the second participant's sub-account at the first payment application specifically includes: The first payment resources held in the first escrow account are transferred to the second participant's sub-account.

7. The method of claim 4, wherein obtaining the payment resources for the target transaction order further comprises: If the transaction platform is required to pay the third payment resources to the second participant for the target transaction order according to the revenue sharing instruction, then the third payment resources in the transaction platform's third payment account at the first payment application will be transferred to the first fund custody account. The step of transferring the payment resources of the target transaction order to the second participant's sub-account at the first payment application further includes: The third payment resources held in the first escrow account are transferred to the second participant's sub-account.

8. The method of claim 7, further comprising, after transferring the payment resources of the target transaction order to the sub-account of the second participant in the first payment application: Obtain the refund instruction from the trading platform for the target transaction order; In response to the refund instruction, the initial transfer account for the payment resources of the target transaction order is determined; the initial transfer account includes at least one of the first payment account, the second payment account, and the third payment account; The payment resources for the target transaction order in the split account are transferred to the initial transfer-out account.

9. The method of claim 7, further comprising, before transferring the payment resources of the target transaction order to the sub-account of the second participant in the first payment application: Obtain the account creation request for the second participant sent by the trading platform; In response to the split account creation request, a split account for the second participant in the first payment application is generated.

10. The method of claim 1, wherein the revenue sharing instruction is a revenue sharing instruction of a trading platform, and the revenue sharing instruction is used to instruct revenue sharing processing for a target transaction order generated at the trading platform; Before transferring the payment resources for the target transaction order to the second participant's sub-account at the first payment application, the method further includes: Obtain the order information of the target transaction order from the trading platform; Risk identification processing is performed based on the order information of the target transaction order to obtain the risk identification result for the target transaction order; The step of transferring the payment resources of the target transaction order to the second participant's sub-account at the first payment application specifically includes: If the risk identification result meets the preset revenue sharing conditions, the payment resources of the target transaction order will be transferred to the revenue sharing account of the second participant in the first payment application.

11. The method of claim 10, further comprising, after performing risk identification processing based on the order information of the target transaction order to obtain a risk identification result for the target transaction order: If the risk identification result does not meet the preset revenue sharing conditions, a revenue sharing prohibition prompt message will be generated; The "Prohibition of Split Revenue" message is used to indicate that split revenue processing is prohibited for the target transaction order based on the risk identification results of the target transaction order.

12. The method of claim 1, wherein the revenue sharing instruction is a revenue sharing instruction of a trading platform, and the revenue sharing instruction is used to instruct revenue sharing processing for a target transaction order generated at the trading platform; The revenue sharing account is an account for which the second participant does not have management authority over account payment resources; After transferring the payment resources of the target transaction order to the second participant's sub-account in the first payment application, the method further includes: Obtain the withdrawal instruction from the trading platform; The withdrawal instruction is used to instruct the transfer of the target payment resources in the sub-account to the fourth payment account of the second participant, wherein the fourth payment account is an account of the second participant that has management authority over the account payment resources; In response to the withdrawal instruction, the target payment resources in the split account are transferred to the fourth payment account of the second participant.

13. A method for profit sharing, comprising: The transaction platform sends a revenue sharing instruction for the target transaction order to the server of the first payment application; The target transaction order is a transaction order in which the first participant uses a target payment application to make a payment to the second participant. The target payment application is either the first payment application or the second payment application. The server of the first payment application responds to the revenue sharing instruction and obtains the payment resources for the target transaction order; The server of the first payment application obtains the order information of the target transaction order from the transaction platform and performs risk identification on the order information of the target transaction order to obtain the risk identification result for the target transaction order; Based on the risk identification results, the server of the first payment application allocates the payment resources for the target transaction order.

14. A revenue-sharing device, applied to the server side of a first payment application, comprising: The first acquisition module is used to acquire the revenue sharing instruction from the trading platform; the revenue sharing instruction is used to instruct revenue sharing processing for the target transaction order generated at the trading platform. The target transaction order is a transaction order in which the first participant uses a target payment application to make a payment to the second participant. The target payment application can be either the first payment application or the second payment application; the second payment application can be any other payment application besides the first payment application. The second acquisition module is used to acquire the payment resources of the target transaction order, including: using the first fund custody account of the first payment application to receive the second payment resources acquired by the target financial institution from the server of the second payment application, wherein the second payment resources are the resources paid by the first participant for the target transaction order using the second payment account of the second payment application; The revenue sharing module is used to transfer the payment resources of the target transaction order to the revenue sharing account of the second participant in the first payment application in response to the revenue sharing instruction, including: transferring the second payment resources in the first fund custody account to the revenue sharing account of the second participant.

15. The apparatus of claim 14, wherein if the target transaction order is a transaction order in which the first participant makes payment using a second payment account in the second payment application, the second acquisition module comprises: The instruction sending unit is used to send a first resource transfer instruction to the target financial institution; The first resource transfer instruction is used to instruct the transfer of a specified amount of payment resources from the target financial institution; A resource receiving unit is configured to receive the specified number of payment resources sent by the target financial institution; the specified number of payment resources includes second payment resources paid by the first participant using the second payment account for the target transaction order; the second payment resources are resources obtained by the target financial institution from the server of the second payment application; The revenue sharing module specifically includes: The first revenue sharing unit is used to transfer the second payment resource from the specified amount of payment resources to the revenue sharing account of the second participant.

16. The apparatus of claim 15, wherein the resource receiving unit is specifically configured to: Using the first fund custody account at the first payment application, a specified amount of payment resources are received from the second fund custody account at the target financial institution; the second fund custody account is used to store the resources obtained by the target financial institution from the server of the second payment application; The first revenue sharing unit is specifically used for: The second payment resources held in the first escrow account are transferred to the second participant's sub-account.

17. The apparatus of claim 16, further comprising: The third acquisition module is used to acquire the second resource transfer instruction sent by the trading platform; The second resource transfer instruction is used to instruct the acquisition of the specified amount of payment resources from the target financial institution.

18. The apparatus of claim 14, wherein if the target transaction order is a transaction order in which the first participant makes payment using the first payment account of the first payment application, the second acquisition module comprises: The first resource transfer unit is used to transfer the first payment resources paid by the first participant using the first payment account for the target transaction order from the first payment account to the first fund custody account of the first payment application. The revenue sharing module includes: The second revenue sharing unit is used to transfer the first payment resources in the first fund custody account to the revenue sharing account of the second participant.

19. The apparatus of any one of claims 16-18, wherein the second acquisition module further comprises: The second resource transfer unit is used to transfer the third payment resources in the third payment account of the transaction platform at the first payment application to the first fund custody account if it is determined according to the revenue sharing instruction that the transaction platform needs to pay the third payment resources to the second participant for the target transaction order. The revenue sharing module also includes: The third revenue-sharing unit is used to transfer the third payment resources in the first fund custody account to the revenue-sharing account of the second participant.

20. The apparatus of claim 19, further comprising: The fourth acquisition module is used to acquire the refund instruction for the target transaction order from the transaction platform; The account determination module is used to determine the initial transfer-out account of the payment resources of the target transaction order in response to the refund instruction; the initial transfer-out account includes at least one of the first payment account, the second payment account, and the third payment account; The reimbursement module is used to transfer the payment resources of the target transaction order in the reimbursement account to the initial transfer-out account.

21. The apparatus of claim 19, further comprising: The fifth acquisition module is used to acquire the account creation request for the second participant sent by the trading platform; The revenue sharing account generation module is used to generate the revenue sharing account of the second participant in the first payment application in response to the revenue sharing account creation request.

22. The apparatus of claim 14, further comprising: The sixth acquisition module is used to acquire the order information of the target transaction order from the transaction platform; The risk identification module is used to perform risk identification processing based on the order information of the target transaction order, and obtain the risk identification result for the target transaction order; The revenue sharing module is specifically used for: If the risk identification result meets the preset revenue sharing conditions, the payment resources of the target transaction order will be transferred to the revenue sharing account of the second participant in the first payment application.

23. The apparatus of claim 22, further comprising: The disallow revenue sharing module is used to generate a disallow revenue sharing prompt message if the risk identification result does not meet the preset revenue sharing conditions. The "Prohibition of Split Revenue" message is used to indicate that split revenue processing is prohibited for the target transaction order based on the risk identification results of the target transaction order.

24. The apparatus of claim 14, wherein the sub-account is an account for which the second participant does not have management authority over account payment resources; the apparatus further comprises: The seventh acquisition module is used to acquire withdrawal instructions from the trading platform; The withdrawal instruction is used to instruct the transfer of the target payment resources in the sub-account to the fourth payment account of the second participant, wherein the fourth payment account is an account of the second participant that has management authority over the account payment resources; The withdrawal module is used to transfer the target payment resources in the split account to the fourth payment account of the second participant in response to the withdrawal instruction.

25. A revenue-sharing device, wherein the revenue-sharing device is a server-side device for a first payment application, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Obtain a splitting instruction for splitting the revenue for a target transaction order; the target transaction order is a transaction order in which a first participant makes a payment to a second participant using a target payment application, and the target payment application is either the first payment application or the second payment application. Obtain the payment resources for the target transaction order; In response to the revenue sharing instruction, the payment resources for the target transaction order are transferred to the revenue sharing account of the second participant in the first payment application.

Images