Transaction switching method, apparatus and device based on multi-service system, and medium

Abstract

The present application belongs to the field of transaction payment. Disclosed are a transaction switching method, apparatus and device based on a multi-service system, and a medium. The method comprises: receiving a transaction request, which comprises at least one transaction sub-request, wherein each transaction sub-request comprises a payer element, a payee element, an account acceptor element, an account element and a transaction resource element, and different transaction sub-requests in the same transaction request differ in at least one of the account acceptor element, the account element and the transaction resource element; on the basis of the transaction request, determining an acceptance resource quantity and generating an acceptance request, wherein the acceptance request comprises the payer element, the payee element, the account element and the acceptance resource quantity; and sending the acceptance request to an account acceptor indicated by the account acceptor element, such that the account acceptor completes a transaction on the basis of the acceptance request.

Description

Transaction switching method, device and equipment based on multi-service system and medium

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202410947068.4, filed on July 15, 2024, entitled “Transaction switching method, device and equipment based on multi-service system and medium”, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] The present application belongs to the field of transaction payment, and particularly relates to a transaction switching method, device and equipment based on multi-service system and medium. BACKGROUND

[0004] There are various services in the field of transaction services, such as card transaction service, cardless transaction service, barcode transaction service, ticket transaction service, and points transaction service. In the above services, a switching system needs to be established to establish the service switching between some institutions and other institutions. Different services have different core exchange elements, so different switching systems need to be established for different services. For example, the core exchange element of the card transaction service is the bank card identifier, and the core exchange element of the points transaction service is the points acceptor identifier and the user identifier. The points transaction service cannot reuse the switching system of the card transaction service, and the card transaction service cannot reuse the switching system of the points transaction service. The specificity of the switching system makes it difficult to be compatible with different types of transaction services, and it is even more difficult to realize the fusion service with different types of transaction services. The existing transaction switching system has poor generality and compatibility. SUMMARY

[0005] The embodiments of the present application provide a transaction switching method, device and equipment based on multi-service system and medium, which can improve the generality and compatibility of transaction switching.

[0006] In a first aspect, the embodiments of the present application provide a transaction switching method based on multi-service system, applied to a multi-service system. The method comprises: receiving a transaction request, the transaction request comprising at least one transaction sub-request, each transaction sub-request comprising a payer element, a payee element, an account acceptor element, an account element and a transaction resource element, at least one of the account acceptor element, the account element and the transaction resource element in different transaction sub-requests in the same transaction request being different; determining an acceptor resource amount according to the transaction request, generating an acceptor request, the acceptor request comprising the payer element, the payee element, the account element and the acceptor resource amount; and sending the acceptor request to an account acceptor indicated by the account acceptor element, so that the account acceptor completes the transaction according to the acceptor request.

[0007] In a second aspect, the embodiments of the present application provide a transaction switching device based on a multi-service system, applied to the multi-service system. The device comprises: a receiving module configured to receive a transaction request, the transaction request comprising at least one transaction sub-request, each transaction sub-request comprising a payer element, a payee element, an account acceptor element, an account element and a transaction resource element, at least one of the account acceptor element, the account element and the transaction resource element in different transaction sub-requests in the same transaction request being different; an information processing module configured to determine an acceptance resource amount according to the transaction request, and generate an acceptance request, the acceptance request comprising the payer element, the payee element, the account element and the acceptance resource amount; and a sending module configured to send the acceptance request to an account acceptor indicated by the account acceptor element, so that the account acceptor completes the transaction according to the acceptance request.

[0008] In a third aspect, the embodiments of the present application provide a transaction switching device based on a multi-service system, comprising a processor and a memory storing computer program instructions; and the processor implements the transaction switching method based on the multi-service system of the first aspect when executing the computer program instructions.

[0009] In a fourth aspect, the embodiments of the present application provide a computer readable storage medium, the computer readable storage medium storing computer program instructions, and the computer program instructions are executed by the processor to implement the transaction switching method based on the multi-service system of the first aspect.

[0010] In a fifth aspect, the embodiments of the present application provide a computer program product, comprising a computer program, and the computer program is executed by the processor to implement the transaction switching method based on the multi-service system of the first aspect.

[0011] The embodiment of the application provides a transaction switching method, device, equipment and medium based on a multi-service system. The multi-service system can receive a transaction request in a standard format. The transaction request can include at least one transaction sub-request. The format of the transaction sub-request is unified and standardized. The transaction sub-request can include a payer element, a payee element, an account acceptor element, an account element and a transaction resource element. The multi-service platform can determine the resource amount to be accepted by the account acceptor for the current transaction according to the transaction request, and generate an acceptance request including the payer element, the payee element, the account element and the acceptance resource amount, and send the acceptance request to the account acceptor, so that the account acceptor completes the transaction. The payer element, the payee element, the account acceptor element, the account element and the transaction resource element can highly abstract the core elements of various types of transaction services. In addition, the payer element, the payee element, the account element and the acceptance resource amount can highly abstract the core elements that the account acceptor needs to know about various types of transaction services. The multi-service system and the transaction parties of various types of transaction services can interact through standard message requests, the business expression of various types of transaction services is realized, and the universality and compatibility of transaction switching are improved. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of the application, the drawings needed to be used in the embodiments of the application will be briefly introduced. Those skilled in the art can obtain other drawings according to these drawings without creating any creative labor.

[0013] FIG. 1 is a schematic diagram of an example of different services corresponding to different switching systems in the related art;

[0014] FIG. 2 is a schematic diagram of an example of a multi-service system provided by the embodiment of the application;

[0015] FIG. 3 is a flowchart of a transaction switching method based on a multi-service system provided by an embodiment of the application;

[0016] FIG. 4 is a schematic diagram of an example of a transaction process based on a multi-service system provided by the embodiment of the application;

[0017] FIG. 5 is a schematic diagram of another example of a transaction process based on a multi-service system provided by the embodiment of the application;

[0018] FIG. 6 is a flowchart of a transaction switching method based on a multi-service system provided by another embodiment of the application;

[0019] FIG. 7 is a schematic diagram of an example of a verification process provided by the embodiment of the application;

[0020] FIG. 8 is a schematic diagram of an example of a risk control verification calling verification plug-in provided by the embodiment of the application;

[0021] FIG. 9 is a schematic diagram of another example of a multi-service system according to an embodiment of the present application;

[0022] FIG. 10 is a schematic diagram of a transaction switching device based on a multi-service system according to an embodiment of the present application;

[0023] FIG. 11 is a schematic diagram of a transaction switching device based on a multi-service system according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] The features and exemplary embodiments of various aspects of the present application will be described in detail below, in order to make the purposes, technical solutions and advantages of the present application clearer. The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are intended to explain the present application only, but not to limit the present application. The present application can be implemented without some of the specific details by those skilled in the art. The following description of the embodiments is merely intended to provide a better understanding of the present application by showing examples of the present application. It should be noted that the acquisition, storage, use, processing, etc. of information and data in the embodiments of the present application are authorized by the user or relevant institution and comply with relevant provisions of national laws and regulations.

[0025] There are various businesses in the transaction business field, such as card transaction business, cardless transaction business, barcode transaction business, ticket transaction business, and point transaction business. In the above businesses, a switching system needs to be established to switch the business between some institutions and other institutions. Different businesses have different core exchange elements, so different businesses need to establish different switching systems. For example, the core exchange element of the card transaction business is the bank card identifier, and the core exchange element of the point transaction business is the point acceptor identifier and the user identifier. The point transaction business cannot reuse the switching system of the card transaction business, and the card transaction business cannot reuse the switching system of the point transaction business. FIG. 1 is a schematic diagram of an example of different businesses corresponding to different switching systems in the related art. As shown in FIG. 1, in the card transaction business scenario, the acquirer needs to interact with the card issuer through the card switching system. In a type of cardless transaction business scenario, the merchant or acquirer needs to access the card transaction switching system through the cardless transaction switching system A, and then interact with the card issuer through the card transaction switching system. In another type of cardless transaction business scenario, the payment institution needs to interact with the card issuer through the cardless transaction switching system B, and a network bridge structure can be established between the cardless transaction switching system B and the card transaction switching system. In the barcode transaction business scenario, the acquirer needs to interact with the barcode payment institution through the barcode transaction switching system. In the point transaction business scenario, the channel party needs to interact with the point issuer through the point transaction switching system. In the ticket transaction business scenario, the channel party needs to interact with the ticket issuer through the ticket transaction switching system. As can be seen, the switching systems of different transaction businesses have special purpose, and the special purpose of the switching system makes it unable to support different types of transaction businesses, and it is more difficult to realize the fusion business with different types of transaction businesses. The existing transaction switching system has poor generality and compatibility.

[0026] The present application provides a transaction switching method, device, equipment, system, storage medium and computer program product based on a multi-business system. The core elements of various transaction businesses are highly abstracted, and a type element that can reflect different transaction businesses is added to construct a multi-business system that can support multiple transaction businesses. Any transaction business can be refined into a basic concept model of "a user purchasing a commodity at a merchant from an account opened by the user at an institution to pay a certain amount of a certain type of resource to the merchant", to complete the transaction between the transaction initiator and the transaction acceptor. The multi-business system can realize the interconnection of different types of resources, support combination transactions of different types of accounts and different types of resources, and realize the management, maintenance and use of the permissions of different types of businesses. The multi-business system can be used as a transaction switching system for any transaction business, improving the generality and compatibility of the transaction switching system.

[0027] For the convenience of understanding, a multi-service system provided by an embodiment of the present application is first described. FIG. 2 is a schematic diagram of an example of a multi-service system provided by an embodiment of the present application. As shown in FIG. 2, a merchant / acquiring institution 111, a payment institution 112, a barcode acquiring institution 113, and other acquiring institutions 114 as transaction initiators can access a unified access end 12 through respective normalized standard interfaces, then access a multi-service system 13 through the unified access end 12. A user 115 as a transaction initiator can access the multi-service system 13 through a digital cash register platform 14. The digital cash register platform can be a platform for payment transactions of an e-commerce platform. Issuing institutions 151, 152, 153, 154, and 155 as account acceptors, such as a card issuing institution, a payment institution, an integral issuing institution, a ticket issuing institution, and other resource issuing institutions, can access the unified access end 16 through respective normalized standard interfaces, then access the multi-service system 13 through the unified access end 16.

[0028] The multi-service system-based transaction switching method, device, equipment, storage medium, and computer program product provided by the present application are described below.

[0029] A first aspect of the present application provides a multi-service system-based transaction switching method. The transaction switching method is applied to a multi-service system, that is, the transaction switching method can be executed by the multi-service system. FIG. 3 is a flowchart of a multi-service system-based transaction switching method provided by an embodiment of the present application. As shown in FIG. 3, the multi-service system-based transaction switching method can include steps S201 to S203.

[0030] In step S201, a transaction request is received.

[0031] The transaction request can be initiated by a digital cash register platform, a merchant / acquiring institution, a payment institution, a barcode acquiring institution, or other acquiring institutions. Herein, the transaction request is not limited by the initiator. Regardless of the initiator of the transaction request, the message format of the transaction request received by the multi-service system is consistent. The transaction request is used to request a transaction service. The transaction request can correspond to one transaction, but the transaction can include one order or multiple orders, that is, the transaction request can correspond to one payment order or more than two payment orders, thereby realizing the combined payment of multiple orders. A user of a transaction can use one type of account or multiple types of accounts for combined transactions. The transaction request can include at least one transaction sub-request. The transaction sub-request can be divided according to different account types of the account used by the user for the transaction, or can be divided according to different orders. Herein, the transaction sub-request is not limited.

[0032] Each transaction sub-request can include a payer element, a payee element, an account acceptor element, an account element, and a transaction resource element.

[0033] The payer element is used to represent the relevant information of the payer. In some examples, the payer element can include, but is not limited to, a payer identification, payer personal information, and payer supplementary information. The payer identification is used to identify the payer, for example, the payer identification can include a payer ID. The payer personal information is used to represent the personal identity of the payer, for example, the payer personal information can include a payer name. The payer supplementary information can include other information of the payer that needs to be supplemented, which can be set according to specific scenarios, needs, and the like, for example, the payer supplementary information can include location information of the payer, which can be Global Positioning System (GPS) information, but is not limited thereto.

[0034] The payee element is used to represent the relevant information of the payee, and in the embodiments of the present application, the payee can include a merchant and the like in the transaction. In some examples, the payee element can include, but is not limited to, a payee identification, a payee order identification, and payee supplementary information. The payee identification is used to identify the payee, for example, the payee identification can include a payee ID. The payee order identification includes an order identification associated with the payee in the present transaction, and the payee order identification has uniqueness. The payee supplementary information can include other information of the payee that needs to be supplemented, for example, the payee supplementary information can include location information of the payee, which can be GPS information, but is not limited thereto. In some examples, the transaction request can include a group of payee elements or more than two groups of payee elements, a group of payee elements can represent one payee, and different groups of payee elements represent different payees, that is, one transaction can correspond to more than two payees, thereby realizing the collection of multiple payees in the multi-order payment.

[0035] The account acceptor element is used to represent information of an acceptor of a transaction resource. In some examples, the account acceptor element can include, but is not limited to, an account acceptor type and an account acceptor identification. The account acceptor type is used to represent a type of the account acceptor, for example, the account acceptor type can include an issuing bank, a payment institution, a point issuing party, a ticket issuing party, etc., without limitation. The account acceptor identification is used to identify the account acceptor, for example, the account acceptor identification can include an account acceptor ID. The account element can include, but is not limited to, an account type and an account identification. The account type is used to represent a type of the account, for example, the account type can include a card account, a barcode payment account, a point account, a ticket account, etc. The account identification is used to identify the account, for example, the account identification can include an account ID, which corresponds to the account type, and the account ID can be implemented as a card number, a barcode account ID, a point account ID, a ticket code, etc. The transaction resource element is used to represent a transaction resource. For example, the transaction resource element can include, but is not limited to, a transaction resource amount, a transaction resource unit, a transaction resource type, a transaction standard resource type, and a transaction standard resource conversion ratio. In some examples, the transaction resource element can further include a total transaction resource amount or a total transaction standard resource amount. The transaction resource amount is a quantity of the transaction resource of the transaction resource type corresponding to the transaction sub-request. The transaction resource unit also corresponds to the transaction resource type, for example, if the transaction resource type is the RMB, the transaction resource unit is yuan. The transaction standard resource type represents a type of the transaction resource as a standard, and the transaction resource of the transaction standard resource type is generally used for settlement in the transaction settlement. The transaction standard resource conversion ratio is a conversion ratio of the transaction resource of the transaction resource type to the transaction resource of the transaction standard resource type.

[0036] In some examples, the transaction sub-request can further include an acceptor element and / or an order element. The acceptor element is applied to a transaction in a three-party architecture including a payee, a payer, and an acceptor, and is used to represent the acceptor, which can be a third-party payment institution, etc., without limitation. For example, the acceptor element can include an acceptor identification, which can include an acceptor ID, and the acceptor element can further include an acceptor type. The order element can be used to represent related information of an order, for example, the order element can include order content, etc.

[0037] At least one of the account acceptor element, the account element, and the transaction resource element in the different transaction sub-requests in the same transaction request is different. In the case that the transaction request includes multiple transaction sub-requests, the transaction request can be a request for a combined transaction of multiple types of resources, that is, a multi-business system can support a combined transaction of multiple types of resources such as a payment card, a third-party payment account, points, a ticket, and the like. Correspondingly, the account acceptor element, the account element, and the transaction resource element of the different transaction sub-requests in the transaction request can be different. For example, if the transaction request includes three transaction sub-requests, the first transaction sub-request is used for payment by using a payment card, the second transaction sub-request is used for payment by using a third-party payment account, and the third transaction sub-request is used for payment by using points, the account acceptor element in the first transaction sub-request indicates that the account acceptor is the issuer of the payment card, the account element indicates that the account is the payment card, and the transaction resource element indicates that the payment resource type is an amount. The account acceptor element in the second transaction sub-request indicates that the account acceptor is a third-party payment institution, the account element indicates that the account is the third-party payment account, and the transaction resource element indicates that the payment resource type is an amount. The account acceptor element in the third transaction sub-request indicates that the account acceptor is a point issuer, the account element indicates that the account is a point account, and the transaction resource element indicates that the payment resource type is points. The transaction resource type and the transaction resource amount in the transaction resource element in the transaction sub-request can be determined according to the input of the user triggering the transaction request, that is, the user can select the type and amount of resources used for the transaction by himself / herself.

[0038] By extracting the payer element, the payee element, the account acceptor element, the account element, and the transaction resource element, the transaction request is standardized, so that the multi-business system itself can complete transaction switching according to the same standard format of the transaction request in different business scenarios.

[0039] In some examples, the transaction request can include a payment request and a return request. In the case that the transaction request is a payment request, the implemented transaction is a payment transaction. In the case that the transaction request is a return request, the implemented transaction is a return transaction. The transaction switching method based on the multi-business system in the embodiments of the present application can support partial return or full return in one transaction.

[0040] In step S202, according to the transaction request, the amount of accepted resources is determined, and an acceptance request is generated.

[0041] The amount of the accepted resource is the amount of the resource of the type of the transaction resource corresponding to the account acceptor element in the transaction. In the case that the type of the transaction resource in the transaction resource element of the transaction request corresponds to the type of the account acceptor in the account acceptor element, the amount of the transaction resource in the transaction resource element of the transaction request can be determined as the amount of the accepted resource. In the case that the type of the transaction resource in the transaction resource element of the transaction request does not correspond to the type of the account acceptor in the account acceptor element, the amount of the transaction resource in the transaction resource element of the transaction request can be converted into the amount of the resource of the type of the account acceptor corresponding to the type of the account acceptor in the account acceptor element, and the amount of the resource of the type of the account acceptor obtained by the conversion is determined as the amount of the accepted resource. The acceptance request can include the payer element, the payee element, the account element, and the amount of the accepted resource, and the specific content can be referred to the related description in the above embodiments, which will not be repeated here.

[0042] In step S203, the acceptance request is sent to the account acceptor indicated by the account acceptor element, so that the account acceptor completes the transaction according to the acceptance request.

[0043] After receiving the acceptance request, the account acceptor can determine the payer, the payee, the account involved in the transaction, and the amount of the resource to be accepted, and complete the acceptance according to the payer, the payee, the account involved in the transaction, and the amount of the resource to be accepted. After the account acceptor completes the acceptance, the account acceptor can also send an acceptance response to the multi-business system, and the multi-business system can determine whether the acceptance is successful or failed according to the acceptance response, so as to facilitate subsequent settlement.

[0044] In some examples, the transaction sub-request has a sub-transaction identifier and a transaction family identifier, the sub-transaction identifiers of different transaction sub-requests are different, and the transaction family identifiers of the transaction sub-requests belonging to the same transaction request are the same. The sub-transaction identifier is used to identify the sub-transaction indicated by the transaction sub-request, and the sub-transaction identifier is unique for the transaction sub-request. The transaction family identifier is used to identify the transaction indicated by the transaction request to which the transaction sub-request belongs, and the transaction sub-requests with the same transaction family identifier belong to the same transaction. After receiving the acceptance response of the acceptance request corresponding to each transaction sub-request, the multi-business system can record the sub-transaction identifier and the transaction family identifier of the transaction sub-request to record the sub-transaction.

[0045] By extracting the payer element, the payee element, the account element, and the amount of the accepted resource, the acceptance request is standardized, so that the multi-business system can complete the transaction switching according to the same standard format of the acceptance request in different business scenarios. The standard format of the transaction request and the acceptance request enables the multi-business system to access various types of transaction parties involved in the transaction business and implement the switching of various types of transaction business.

[0046] In the embodiment of the present application, the multi-service system can receive a transaction request in a standard format, the transaction request can include at least one transaction sub-request, the format of the transaction sub-request is uniformly standardized, the transaction sub-request can include a payer element, a payee element, an account acceptor element, an account element and a transaction resource element, the multi-service platform can determine the resource amount to be redeemed by the account acceptor for the current transaction according to the transaction request, and generate a redemption request including the payer element, the payee element, the account element and the redemption resource amount and send it to the account acceptor, so that the account acceptor completes the transaction. By the payer element, the payee element, the account acceptor element, the account element and the transaction resource element, the core elements of various types of transaction services can be highly abstracted, and by the payer element, the payee element, the account element and the redemption resource amount, the core elements that the account acceptor needs to know for various types of transaction services can be highly abstracted, so that the multi-service system and the transaction parties of various types of transaction services can interact through standard message requests, the business expression of various types of transaction services is realized, and the universality and compatibility of transaction switching are improved.

[0047] Moreover, through the setting of each element in the standardized transaction request, the standardized circulation of non-amount resources such as points and coupons can be realized, the non-amount resources such as points and coupons can be converted into amount resources for settlement based on the transaction resource element, so as to ensure the redemption and settlement of transactions. In addition to the conversion of non-amount resources into amount resources, the conversion of non-amount resources into other non-amount resources, and the conversion of amount resources into other amount resources can also be realized, realizing the networking circulation of heterogeneous resources and the transaction circulation of multiple standard resource types. In addition, the transaction switching method based on the multi-service system in the embodiment of the present application can also realize the combination payment of heterogeneous resources, the merger payment of multiple orders, and the account clearing of easy-to-buy resources, improving the flexibility and expansibility of system processing of transaction services.

[0048] In some embodiments, the combination payment of heterogeneous resources is performed, and correspondingly, the transaction request includes a plurality of transaction sub-requests, each transaction sub-request corresponds to one account type, and one acceptance request corresponds to one transaction sub-request. The step S202 can be specifically refined as follows: according to a first transaction sub-request, determining an acceptance resource amount of the first transaction sub-request, and generating an acceptance request corresponding to the first transaction sub-request; in a case where an acceptance response corresponding to the first transaction sub-request is received and a transaction standard resource amount of the first transaction sub-request does not reach a total transaction standard resource amount indicated by the transaction request, according to a second transaction sub-request, determining an acceptance resource amount of the second transaction sub-request, and generating an acceptance request corresponding to the second transaction sub-request, until an acceptance response corresponding to an Nth transaction sub-request is received and a sum of transaction standard resource amounts of the first N transaction sub-requests reaches the total transaction standard resource amount indicated by the transaction request, N being a positive integer greater than or equal to 2.

[0049] In a case where the transaction request includes a plurality of transaction sub-requests, the multi-business system can sequentially receive the transaction sub-requests, and process a next transaction sub-request after processing a current transaction sub-request. The multi-business system receives a first transaction sub-request, determines an acceptance resource amount of the first transaction sub-request according to the first transaction sub-request, generates a first acceptance request, and sends the acceptance request to an account acceptor indicated by the first transaction sub-request. The account acceptor indicated by the first transaction sub-request performs acceptance processing according to the acceptance request, and feeds back a first acceptance response to the multi-business system, the acceptance response representing acceptance success. The multi-business system judges whether a transaction standard resource amount that has been accepted reaches a total transaction standard resource amount of the current transaction, and if not, receives a second transaction sub-request, determines an acceptance resource amount of the second transaction sub-request according to the second transaction sub-request, generates a second acceptance request, and sends the acceptance request to an account acceptor indicated by the second transaction sub-request. In this way, until an acceptance response is fed back by an account acceptor indicated by an Nth transaction sub-request, and a transaction standard resource amount that has been accepted reaches the total transaction standard resource amount of the current transaction, the multi-business system can no longer receive other transaction sub-requests in the current transaction request.

[0050] In some examples, the transaction request triggers a transaction platform, which can be implemented as an e-commerce platform, without limitation. When the multi-business system receives the acceptance response corresponding to the Nth transaction sub-request and the sum of the transaction standard resource amounts of the first N transaction sub-requests reaches the total transaction standard resource amount indicated by the transaction request, the multi-business system sends a transaction notification to the transaction platform that triggered the transaction request, where the transaction notification is used to notify the transaction platform that the current transaction has been successfully completed. The transaction notification has a sub-transaction identifier and a transaction family identifier, and the transaction family identifier of the transaction notification is the same as the transaction family identifier of the transaction request. The transaction notification can be regarded as the N+lth sub-transaction in the transaction indicated by the transaction request, but the N+lth sub-transaction is mainly used to notify the transaction platform, so that the transaction platform can align information with the multi-business platform, and no new resource deduction is generated. The N sub-transaction requests correspond to a sub-transaction, and the N+lth sub-transaction corresponding to the transaction notification can be associated through the transaction family identifier. The multi-business system records the transaction family identifier and the sub-transaction identifier of the N+lth sub-transaction, so as to facilitate subsequent clearing through the transaction family identifier.

[0051] For ease of understanding, the combination payment of heterogeneous resources is taken as an example to describe the transaction switching method based on the multi-business system in the embodiments of the present application. FIG. 4 is a schematic diagram of an example of a transaction process based on a multi-business system provided by the embodiments of the present application. In this example, a user places an order through a transaction platform, selects a payment card, a third-party payment account, and communication points for combination payment to complete a payment of 200 yuan, as shown in FIG. 4. The transaction process can include steps a1 to a24.

[0052] In step a1, the user initiates a payment order to the transaction platform. The total amount of the payment order is 200 yuan.

[0053] In step a2, the transaction platform invokes the digital cash register platform.

[0054] In step a3, the user inputs the payment amount of the payment card to the digital cash register platform. The payment amount of the payment card is 50 yuan.

[0055] In step a4, the digital cash register platform sends a first transaction sub-request to the multi-business system. In the first transaction sub-request, the account acceptor element indicates that the account acceptor is the issuer of the payment card, the account element indicates that the account is the payment card, the total amount of the transaction standard resource, i.e., the total amount, is 200 yuan, the transaction resource amount of the sub-transaction is 50 yuan, the transaction resource type and the transaction standard resource type are Chinese yuan, and the transaction standard resource conversion ratio is 1:1.

[0056] In step a5, the multi-service system sends a first acceptance request to the issuer of the payment card according to the first transaction sub-request. The acceptance resource amount in the acceptance request is 50 yuan.

[0057] In step a6, the multi-service system receives an acceptance response sent by the issuer of the payment card. The acceptance response indicates that the acceptance is successful.

[0058] In step a7, the multi-service system records the sub-transaction identifier TransIdl and the transaction family identifier TransFamilyId of the first sub-transaction.

[0059] In step a8, the multi-service system sends a transaction response to the digital cashier platform. The transaction response indicates that the amount to be paid in this transaction is 150 yuan.

[0060] In step a9, the user inputs the payment amount of the third-party payment account to the digital cashier platform. The payment amount of the third-party payment account is 90 yuan.

[0061] In step a10, the digital cashier platform sends a second transaction sub-request to the multi-service system. In the second transaction sub-request, the account acceptor indicated by the account acceptor element is the third-party payment institution, the account indicated by the account element is the third-party payment account, the total amount of transaction standard resources indicated by the transaction resource element is 200 yuan, the transaction resource amount of this sub-transaction indicated by the transaction resource element is 90 yuan, the transaction resource type and the transaction standard resource type indicated by the transaction resource element are RMB, and the transaction standard resource conversion ratio indicated by the transaction resource element is 1:1.

[0062] In step a11, the multi-service system sends a second acceptance request to the issuer of the payment card according to the second transaction sub-request. The acceptance resource amount in the acceptance request is 90 yuan.

[0063] In step a12, the multi-service system receives an acceptance response sent by the issuer of the payment card. The acceptance response indicates that the acceptance is successful.

[0064] In step a13, the multi-service system records the sub-transaction identifier TransId2 and the transaction family identifier TransFamilyId of the second sub-transaction.

[0065] In step a14, the multi-service system sends a transaction response to the digital cashier platform. The transaction response indicates that the amount to be paid in this transaction is 60 yuan.

[0066] In step a15, the user inputs the payment credit amount of the points to the digital cashier platform. The payment credit amount is 6000, the conversion ratio of points to money is 100:1, and 6000 points correspond to a payment amount of 60 yuan.

[0067] In step a16, the digital cash register platform sends a third transaction sub-request to the multi-service system. In the third transaction sub-request, the account acceptor element indicates that the account acceptor is the communication credit issuer, the account element indicates that the account is the credit account, the total amount of transaction standard resources indicated by the transaction resource element is 200 yuan, the transaction resource amount of the sub-transaction indicated by the transaction resource element is 6000 credits, the transaction resource type and the transaction standard resource type indicated by the transaction resource element are RMB, and the transaction standard resource conversion ratio indicated by the transaction resource element is 100:1.

[0068] In step a17, the multi-service system sends a first acceptance request to the payment card issuing bank according to the third transaction sub-request. The acceptance resource amount in the acceptance request is 6000 credits.

[0069] In step a18, the multi-service system receives an acceptance response sent by the communication credit issuer. The acceptance response indicates that the acceptance is successful.

[0070] In step a19, the multi-service system records the sub-transaction identifier TransId3 and the transaction family identifier TransFamilyId of the third sub-transaction.

[0071] In step a20, the multi-service system sends a transaction response to the digital cash register platform. The multi-service system converts the credits into money according to the conversion ratio of credits and money, and obtains the payment amount of the third sub-transaction as 60 yuan. The transaction response indicates that the payment amount of the transaction is 0 yuan.

[0072] In step a21, the multi-service system sends a transaction notification to the transaction platform. The transaction notification indicates that the payment amount of the transaction is 0 yuan and 200 yuan has been paid.

[0073] In step a22, the multi-service system records the sub-transaction identifier TransId4 and the transaction family identifier TransFamilyId of the fourth sub-transaction. It should be noted that the notification to the transaction platform is regarded as the fourth sub-transaction here, but the fourth sub-transaction is only for notification, which is for the convenience of settlement of the transaction platform, and does not generate a new payment amount.

[0074] In step a23, the transaction platform feeds back a transaction notification response to the multi-service system.

[0075] In step a24, the multi-service system sends a transaction completion notification to the digital cash register platform. The transaction completion notification indicates that the transaction is completed.

[0076] The other specific contents of steps a1 to a24 described above can be referred to the related descriptions in the above embodiments, which will not be repeated here.

[0077] In the case that the transaction resource type in the transaction sub-request is different from the transaction standard resource type, in order to facilitate settlement, it is necessary to convert the transaction resource quantity corresponding to the transaction resource type into the transaction standard resource quantity corresponding to the transaction standard resource type, especially for non-monetary resources such as points. The account of the account acceptor of the non-monetary resources can be pre-opened to facilitate the transfer of resources in the standard resource account to the account of the payee. The transaction resource elements include transaction resource quantity, transaction resource type, transaction standard resource type and transaction standard resource conversion rate. In the case that the transaction resource type in the transaction sub-request is different from the transaction standard resource type, the multi-business system converts the transaction resource quantity in the transaction sub-request into the transaction standard resource quantity corresponding to the transaction standard resource type according to the transaction standard resource conversion rate; and uses the standard resource account pre-set by the account acceptor indicated by the account acceptor element in the transaction sub-request to complete the transaction according to the converted transaction standard resource quantity.

[0078] In some cross-border transaction scenarios, conversion of two types of transaction standard resources is required, one of which is an overseas transaction standard resource and the other is a domestic transaction standard resource. In the conversion of the two types of transaction standard resources, one type of transaction standard resource is used as an intermediate conversion transaction standard resource, and the other type is used as a final conversion transaction standard resource. The account acceptor of the cross-border transaction can pre-sign a pre-conversion contract with the multi-business system, and the multi-business system pre-stores the pre-conversion contract. The pre-conversion contract can include a pre-transaction standard resource type and a pre-transaction standard resource conversion rate. The pre-transaction standard resource type is the intermediate conversion transaction standard resource type, and the pre-transaction standard resource conversion rate is the intermediate conversion transaction standard resource conversion rate. The transaction resource elements in the transaction sub-request include transaction resource quantity, transaction resource type, transaction standard resource type and transaction standard resource conversion rate. The above step S202 can be specifically refined as follows: in the case that the transaction resource type in the transaction sub-request is different from the transaction standard resource type and the account acceptor indicated by the account acceptor element in the transaction sub-request has a pre-conversion contract, the multi-business system converts the transaction resource quantity in the transaction request into a pre-transaction standard resource quantity corresponding to the pre-transaction standard resource type according to the pre-transaction standard resource conversion rate; converts the pre-transaction standard resource quantity into a transaction standard resource quantity corresponding to the transaction standard resource type in the transaction sub-request, and determines the converted transaction standard resource quantity as the accepted resource quantity.

[0079] For example, if a user desires to complete payment on an e-commerce platform in country A2 using bank points in country A1, the bank in country A1 can sign a pre-conversion contract with the multi-service platform in advance, in which the pre-transaction standard resource type is the transaction standard resource type in country A1, and the pre-transaction standard resource conversion ratio is the conversion ratio of bank points in country A1 to transaction standard resources of the transaction standard resource type in country A1. The multi-service system can convert the bank points in country A1 to the transaction standard resource amount of the transaction standard resource type in country A1 according to the pre-transaction standard resource, and then convert the transaction standard resource amount of the transaction standard resource type in country A1 to the transaction standard resource amount of the transaction standard resource type in country A2, and determine the transaction standard resource amount of the transaction standard resource type in country A2 as the acceptance resource amount, to generate an acceptance request.

[0080] In some embodiments, the multi-service system can also implement conversion of transaction resources of two transaction resource types through transaction resources of another transaction resource type. The transaction resource element can include a first transaction standard resource type, a first transaction standard resource conversion ratio, a second transaction standard resource type, and a second transaction standard resource conversion ratio. The first transaction standard resource type corresponds to the first transaction standard resource conversion ratio, and the second transaction standard resource type corresponds to the second transaction standard resource conversion ratio. The above step S202 can be specifically refined as: converting the transaction resource amount in the transaction sub-request to a first transaction standard resource amount corresponding to the first transaction standard resource type according to the first transaction standard resource conversion ratio; converting the first transaction standard resource amount to a second transaction standard resource amount corresponding to the second transaction standard resource type according to the second transaction standard resource conversion ratio, and determining the second transaction standard resource amount as the acceptance resource amount, to generate an acceptance request.

[0081] For ease of understanding, the following will take an example of conversion of points and air miles through RMB amounts to illustrate the transaction switching method based on the multi-service system in the embodiments of the present application. FIG. 5 is a schematic diagram of another example of a transaction process based on a multi-service system provided by the embodiments of the present application, in which a user requests conversion of bank points to air miles of an airline through a third-party payment institution, as shown in FIG. 5. The transaction process can include steps b1 to b9.

[0082] In step b1, the user initiates the exchange to the third-party payment institution. The third-party payment institution is the receiving party in this example.

[0083] In step b2, the third-party payment institution sends a transaction request to the multi-service system. The transaction request is used to request conversion of 100 bank points to air miles of an airline.

[0084] In step b3, the multi-business system sends a transfer-in acceptance request to the bank. The transfer-in acceptance request is used to request the transfer of 100 bank points into the bank account of the user. The bank is the payee in this example.

[0085] In step b4, the bank sends a transfer-in acceptance response to the multi-business system. The transfer-in acceptance response indicates that the bank points have been successfully transferred.

[0086] In step b5, the multi-business system performs the conversion of the transaction resources. Specifically, the first transaction standard resource type is the RMB, the first transaction standard resource conversion ratio is 100:1, i.e., 100 bank points can be converted into 1 RMB, and the second transaction standard resource type is the mileage, the second transaction standard resource conversion ratio is 1:500, i.e., 1 RMB can be converted into 500 miles.

[0087] In step b6, the multi-business system sends a transfer-in acceptance request to the airline. The transfer-in acceptance request is used to request the transfer of the converted 500 miles into the account of the user in the airline. The airline is the payee in this example.

[0088] In step b7, the airline sends a transfer-in acceptance response to the multi-business system. The transfer-in acceptance response indicates that the miles have been successfully transferred.

[0089] In step b8, the multi-business system sends a transaction response to the third-party payment institution. The transaction response indicates that the transaction is successful.

[0090] In step b9, the third-party payment institution shows the user a transaction result indicating that the transaction is successful.

[0091] The other specific contents of steps b1 to b9 described above can be found in the related descriptions in the above embodiments, which will not be repeated here.

[0092] In some embodiments, after receiving the transaction request, the current transaction can be verified first, and then the subsequent transaction process is performed after the verification is passed. Various verification functions can be realized through flexible verification plug-ins, and the circulation capacity of resources, the circulation capacity of the account acceptance party, the circulation capacity of the payee, and the circulation capacity of the payee, etc. are comprehensively managed to ensure transaction security. The verification plug-in adopts a unified standard input parameter and output parameter, and the call of the verification plug-in is also standardized. In the case of functional update of the multi-business system, the updated function can be realized by adding a plug-in. The newly added plug-in will not affect the original business function logic, and the plug-in can be plugged in and out to realize the flexible expansion of the transaction business.

[0093] FIG. 6 is a flowchart of a transaction switching method based on a multi-service system according to another embodiment of the present application. The transaction switching method based on a multi-service system shown in FIG. 6 is different from that shown in FIG. 3 in that the transaction switching method based on a multi-service system shown in FIG. 6 further includes step S204, and step S202 in FIG. 3 can be specifically refined as step S2021 shown in FIG. 6.

[0094] In step S204, according to the transaction request, a verification plug-in corresponding to the account element is called to verify the transaction indicated by the transaction request.

[0095] The verification plug-in called is different according to the account element included in the transaction sub-request in the transaction request. The verification plug-in to be called can be determined according to the account element included in the transaction sub-request in the transaction request, and the verification plug-in is called to perform verification of the transaction indicated by the transaction request by the verification plug-in.

[0096] In some examples, the verification plug-in can be used to verify one or two or more of the transaction resource element, the account acceptor element, the payer element, and the payee element. The verification plug-in includes one or two or more of the permission verification plug-in, the quota verification plug-in, and the risk control verification plug-in. The permission verification plug-in can further include a transaction resource permission verification plug-in, an account acceptor permission verification plug-in, a payer permission verification plug-in, and a payee permission verification plug-in. The quota verification plug-in can further include a transaction resource quota verification plug-in, an account acceptor quota verification plug-in, a payer quota verification plug-in, and a payee quota verification plug-in. The risk control verification plug-in can further include a transaction resource risk control verification plug-in, an account acceptor risk control verification plug-in, a payer risk control verification plug-in, and a payee risk control verification plug-in.

[0097] For example, FIG. 7 is a schematic diagram of an example of the verification process provided by the embodiments of the present application. As shown in FIG. 7, the permission verification, the quota verification, and the risk control verification can be performed in sequence, and other verifications can also be performed. The permission verification can include the permission verification of the transaction resource circulation, the permission verification of the account acceptor circulation, the permission verification of the payer circulation, and the permission verification of the payee circulation. The permission verification of the transaction resource circulation can be the access permission verification of the transaction resource according to the pre-set transaction resource switch, the transaction resource white list, the transaction resource black list, and the like, that is, the verification of whether the transaction resource is allowed to circulate in the transaction business. The permission verification of the account acceptor circulation can be the verification of the permission of the account acceptor according to the pre-set hierarchical rule, which can be set according to the account acceptor, the acceptance quota of the account acceptor, the account acceptor white list, the white list of the transaction that the account acceptor can participate in, and the like. The permission verification of the payer circulation can be the verification according to the pre-set white list, yellow list, and black list. The permission verification of the payee circulation can be the verification according to the pre-set white list, yellow list, and black list. Similarly, the quota verification can include the quota verification of the transaction resource circulation, the quota verification of the account acceptor circulation, the quota verification of the payer circulation, and the quota verification of the payee circulation. The quota verification is similar to the above-mentioned permission verification, but the verification is mainly based on the quota, and the quota of the transaction resource, the account acceptor, the payer, and the payee can be verified according to the pre-set quota rule. The risk control verification can include the risk control verification of the transaction resource circulation, the risk verification of the account acceptor circulation, the risk verification of the payer circulation, and the risk verification of the payee circulation. The risk control verification is similar to the above-mentioned permission verification, but the verification is mainly based on the risk control, and the risk control of the transaction resource, the account acceptor, the payer, and the payee can be verified according to the pre-set risk rule, risk white list, risk yellow list, risk black list, and the like.

[0098] Through the verification of the transaction resource, the account acceptor, the payer, and the payee, the transaction security is improved. The verification rules set in the verification plug-in can realize the flexible configuration of the verification, and the efficient verification can be realized.

[0099] The input data and the output data of the verification plug-in in the above embodiment are standardized, and the verification plug-in can process the standardized input data to obtain a verification result. Specifically, the multi-business system can obtain standard input data required by the verification plug-in from a transaction request, call the verification plug-in, input the standard input data into the verification plug-in, so that the verification plug-in outputs verification result standard data based on the standard input data, and obtain the verification result standard data from the verification plug-in. The standard input data can include a payer account identifier, a transaction resource amount, a transaction resource type, a payee identifier, and a verification type, the verification type corresponds to an account type indicated by the account element, and in some examples, the verification type can be directly assigned with the account type. The verification result standard data includes a verification result.

[0100] For example, FIG. 8 is a schematic diagram of an example of a risk control verification calling a verification plug-in provided by an embodiment of the present application. As shown in FIG. 8, the verification plug-in that can be called by the risk control verification can include a payment card risk verification plug-in, a point risk verification plug-in, and other verification plug-ins. Each verification plug-in can be registered in a plug-in registration center in advance, and the multi-business system can subscribe to the verification plug-in that needs to be called from the plug-in registration center in advance. When it is needed to be called, the corresponding plug-in is called. For example, if the account indicated by the account element is a payment card, the payment card risk verification plug-in is called; if the account indicated by the account element is a point account, the point risk verification plug-in is called. The standard input data of the verification plug-in can include a payer account identifier PayerAcctId, a transaction resource amount TrxTmt, a transaction resource type currency, a payee identifier merchantNO, and a verification type serviceGroup. The verification result standard data of the verification plug-in can include a risk score score.

[0101] In step S2021, in the case of passing the verification, the transaction resource amount is determined according to the transaction request, and a confirmation request is generated.

[0102] If the verification fails, the transaction is aborted.

[0103] It should be noted that the functions other than the verification in the multi-business system in the embodiment of the present application can also be implemented by the plug-in, for example, the conversion, clearing, and other functions of the transaction resource can be implemented as a plug-in. The embodiment of the present application can support the plug-in of each access party in the aspects of access, authority, limit, risk control, operation management, and the like, each plug-in can be dynamically loaded and unloaded, and the newly added function logic is implemented by the plug-in, which does not affect the original business function logic, so that the implementation of the transaction business is more flexible.

[0104] In some embodiments, time is needed for the access party of the multi-service system to modify the access. When the access party of the multi-service system has not been successfully modified, the system transition stage can be set for the access party of the multi-service system, and the pre-compatibility system and the post-compatibility system are configured for the multi-service system, and the pre-compatibility system and the post-compatibility system are used to compatibly process the message protocol and the interface type of the original interface. The pre-compatibility system is used to convert the request sent by the original interface of the access party into a transaction request meeting the requirements of the multi-service system, and the post-compatibility system is used to convert the acceptance request output by the multi-service system into a request meeting the requirements of the original interface of the access party. The access party can include a transaction initiator and an account acceptor, and the transaction initiator can include a user, a third-party payment institution, a transaction platform, a digital cash register platform, a collecting institution, etc.

[0105] In the system transition stage, the pre-compatibility system is used to convert the request sent by the transaction initiator using the original interface into a transaction request. In the system transition stage, the post-compatibility system is used to convert the acceptance request into a request meeting the requirements of the original interface of the account acceptor, and send the request to the account acceptor. For example, FIG. 9 is a schematic diagram of another example of the multi-service system provided by an embodiment of the present application. The difference between FIG. 9 and FIG. 2 is that the multi-service system 13 shown in FIG. 9 is further configured with a pre-compatibility system 17 and a post-compatibility system 18. The merchant / collection institution 111, the payment institution 112, the bar code collection institution 113, and the other collection institutions 114 can access the unified access end 12 through the normalized standard interface, and the merchant / collection institution 111, the payment institution 112, the bar code collection institution 113, and the other collection institutions 114 can access the pre-compatibility system 17 through the original interface. The card issuing institution 151, the payment institution 152, the point issuing party 153, the ticket issuing party 154, and the other resource issuing party 155 can access the unified access end 16 through the normalized standard interface, and the card issuing institution 151, the payment institution 152, the point issuing party 153, the ticket issuing party 154, and the other resource issuing party 155 can access the post-compatibility system 18 through the original interface.

[0106] The second aspect of the present application provides a transaction switching device based on a multi-service system, which is applied to the multi-service system. FIG. 10 is a structural schematic diagram of the transaction switching device based on the multi-service system provided by an embodiment of the present application. As shown in FIG. 10, the transaction switching device based on the multi-service system 300 can include a receiving module 301, an information processing module 302, and a sending module 303.

[0107] The receiving module 301 can be used to receive a transaction request.

[0108] The transaction request comprises at least one transaction sub-request. Each transaction sub-request comprises a payer element, a payee element, an account acceptor element, an account element and a transaction resource element. At least one of the account acceptor element, the account element and the transaction resource element in different transaction sub-requests in the same transaction request is different.

[0109] The information processing module 302 can be configured to determine the amount of acceptance resource according to the transaction request, and generate an acceptance request.

[0110] The acceptance request comprises a payer element, a payee element, an account element and an amount of acceptance resource.

[0111] The sending module 303 can be configured to send the acceptance request to the account acceptor indicated by the account acceptor element, so that the account acceptor completes the transaction according to the acceptance request.

[0112] In some embodiments, the transaction request comprises a plurality of transaction sub-requests, and each transaction sub-request corresponds to one account type. The information processing module 302 can be specifically configured to: determine the amount of acceptance resource of a first transaction sub-request according to the first transaction sub-request, and generate an acceptance request corresponding to the first transaction sub-request; in a case where an acceptance response corresponding to the first transaction sub-request is received and the amount of transaction standard resource of the first transaction sub-request does not reach the total amount of transaction standard resource indicated by the transaction request, determine the amount of acceptance resource of a second transaction sub-request according to the second transaction sub-request, and generate an acceptance request corresponding to the second transaction sub-request, until an acceptance response corresponding to an Nth transaction sub-request is received and the sum of the amounts of transaction standard resource of the first N transaction sub-requests reaches the total amount of transaction standard resource indicated by the transaction request, where N is a positive integer greater than or equal to 2.

[0113] In some embodiments, the information processing module 302 can be further configured to: in a case where the acceptance response corresponding to the Nth transaction sub-request is received and the sum of the amounts of transaction standard resource of the first N transaction sub-requests reaches the total amount of transaction standard resource indicated by the transaction request, send a transaction notification to a transaction platform triggering the transaction request.

[0114] The transaction notification has a sub-transaction identifier and a transaction family identifier, and the transaction family identifier of the transaction notification is the same as the transaction family identifier of the transaction request.

[0115] In some embodiments, the transaction resource element includes a transaction resource amount, a transaction resource type, a transaction standard resource type, and a transaction standard resource conversion ratio. The information processing module 302 can be further configured to: in a case where the transaction resource type in the transaction sub-request is different from the transaction standard resource type, convert the transaction resource amount in the transaction sub-request into a transaction standard resource amount corresponding to the transaction standard resource type according to the transaction standard resource conversion ratio; and complete the transaction according to the converted transaction standard resource amount by using a standard resource account of the account acceptor indicated by the account acceptor element in the transaction sub-request.

[0116] In some embodiments, the transaction sub-request has a sub-transaction identifier and a transaction family identifier, the sub-transaction identifiers of different transaction sub-requests are different, and the transaction family identifiers of the transaction sub-requests belonging to the same transaction request are the same.

[0117] In some embodiments, the transaction resource element includes a transaction resource amount, a transaction resource type, a transaction standard resource type, and a transaction standard resource conversion ratio, and the multi-service system pre-stores a pre-conversion contract, the pre-conversion contract including a pre-transaction standard resource type and a pre-transaction standard resource conversion ratio.

[0118] The information processing module 302 can be specifically configured to: in a case where the transaction resource type in the transaction sub-request is different from the transaction standard resource type and the account acceptor indicated by the account acceptor element in the transaction sub-request has a pre-conversion contract, convert the transaction resource amount in the transaction request into a pre-transaction standard resource amount corresponding to the pre-transaction standard resource type according to the pre-transaction standard resource conversion ratio; convert the pre-transaction standard resource amount into a transaction standard resource amount corresponding to the transaction standard resource type in the transaction sub-request, and determine the converted transaction standard resource amount as the accepted resource amount.

[0119] In some embodiments, the transaction resource element includes a first transaction standard resource type, a first transaction standard resource conversion ratio, a second transaction standard resource type, and a second transaction standard resource conversion ratio. The information processing module 302 can be specifically configured to: convert the transaction resource amount in the transaction sub-request into a first transaction standard resource amount corresponding to the first transaction standard resource type according to the first transaction standard resource conversion ratio; convert the first transaction standard resource amount into a second transaction standard resource amount corresponding to the second transaction standard resource type according to the second transaction standard resource conversion ratio, and determine the second transaction standard resource amount as the accepted resource amount.

[0120] In some embodiments, the transaction switching device 300 based on the multi-service system can further include a verification module. The verification module can be configured to: according to the transaction request, call a verification plug-in corresponding to the account element, and verify the transaction indicated by the transaction request.

[0121] The information processing module 302 can be specifically configured to: in the case of passing the verification, determine the amount of the acceptance resource according to the transaction request, and generate an acceptance request.

[0122] In some examples, the verification plug-in is used to verify one or more of the transaction resource element, the account acceptance party element, the payer element, and the payee element. The verification plug-in includes one or more of the permission verification plug-in, the quota verification plug-in, and the risk control verification plug-in.

[0123] In some examples, the verification module can be specifically configured to: obtain standard input data required by the verification plug-in from the transaction request; call the verification plug-in and input the standard input data into the verification plug-in, so that the verification plug-in outputs verification result standard data based on the standard input data; and obtain the verification result standard data from the verification plug-in.

[0124] In some examples, the transaction request includes a payment request and a return request.

[0125] In some embodiments, the multi-service system is configured with a front-end compatibility system and a back-end compatibility system. The transaction switching device 300 of the multi-service system further includes a conversion module, which can be used to: in the system transition phase, convert the request sent by the transaction initiator using the original interface into a transaction request through the front-end compatibility system; and in the system transition phase, convert the acceptance request into a request meeting the requirements of the original interface of the account acceptance party through the back-end compatibility system, and send the request to the account acceptance party.

[0126] In some examples, the transaction request corresponds to one payment order or two or more payment orders. The transaction sub-request in the transaction request includes one set of payee elements or two or more sets of payee elements.

[0127] In some examples, the payer element includes a payer identifier, payer personal information, and payer supplementary information.

[0128] The payee element includes a payee identifier, a payee order identifier, and payee supplementary information.

[0129] The account element includes an account type and an account identifier.

[0130] The account acceptance party element includes an account acceptance party type and an account acceptance party identifier.

[0131] The transaction resource element includes a transaction resource amount, a transaction resource unit, a transaction resource type, a transaction standard resource type, and a transaction standard resource conversion ratio.

[0132] In some examples, the transaction sub-request further includes a receiving party element and / or an order element.

[0133] It should be noted that the transaction switching device 300 based on the multi-service system is a device corresponding to the transaction switching method based on the multi-service system described above, and all the implementation manners in the method embodiments are applicable to the device embodiments, and the same technical effects can be achieved.

[0134] The third aspect of the present application further provides a transaction switching device based on a multi-service system. FIG. 11 is a structural schematic diagram of a transaction switching device based on a multi-service system according to an embodiment of the present application. As shown in FIG. 11, the transaction switching device 400 based on the multi-service system includes a memory 401, a processor 402, and a computer program stored in the memory 401 and executable on the processor 402.

[0135] In some examples, the processor 402 described above can include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement one or more embodiments of the present application.

[0136] The memory 401 can include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical, or other physical / tangible memory storage device. Therefore, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions and when the software is executed (e.g., by one or more processors), it is operable to perform operations described with reference to the transaction switching method based on a multi-service system according to embodiments of the present application.

[0137] The processor 402 runs a computer program corresponding to the executable program code stored in the memory 401 by reading the executable program code, to implement the transaction switching method based on a multi-service system in the above-described embodiments.

[0138] In some examples, the transaction switching device 400 based on the multi-service system can further include a communication interface 403 and a bus 404. As shown in FIG. 11, the memory 401, the processor 402, and the communication interface 403 are connected through the bus 404 and complete communication with each other.

[0139] The communication interface 403 is mainly used to implement communication between modules, devices, units, and / or equipment in embodiments of the present application. Input devices and / or output devices can also be accessed through the communication interface 403.

[0140] Bus 404 includes a hardware, software, or both that couples components of transaction brokering device 400 based on a multi-service system to each other. By way of example, and not limitation, bus 404 can be an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand™ interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or some other suitable bus or a combination of two or more of these. Where appropriate, bus 404 can include one or more buses. Although this application describes and shows a particular bus, this application contemplates any suitable bus or interconnect.

[0141] A computer readable storage medium is provided in the fourth aspect of the present application, and the computer program instructions stored on the computer readable storage medium can implement the transaction brokering method based on a multi-service system in the above embodiments when executed by a processor, and achieve the same technical effects. To avoid repetition, details are not described herein. The computer readable storage medium can include a non-transitory computer readable storage medium, such as a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disc or an optical disc, and the like, which is not limited herein.

[0142] A computer program product is provided in the fifth aspect of the present application, and the computer program included in the computer program product can implement the transaction brokering method based on a multi-service system in the above embodiments when executed by a processor, and achieve the same technical effects. To avoid repetition, details are not described herein.

[0143] It should be clarified that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. For the device embodiments, equipment embodiments, computer-readable storage medium embodiments, and computer program product embodiments, the relevant parts can be referred to the description section of the method embodiments. This application is not limited to the specific steps and structures described above and shown in the figures. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application. Furthermore, for the sake of brevity, detailed descriptions of known methods and techniques are omitted here.

[0144] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in 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, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0145] Those skilled in the art will understand that the above embodiments are exemplary and not restrictive. Different technical features appearing in different embodiments can be combined to achieve beneficial effects. Based on a study of the drawings, specification, and claims, those skilled in the art should be able to understand and implement other variations of the disclosed embodiments. In the claims, the term "comprising" does not exclude other means or steps; the quantifier "a" does not exclude a plurality; the terms "first" and "second" are used to identify names and not to indicate any particular order. No reference numerals in the claims should be construed as limiting the scope of protection. The functionality of multiple parts appearing in the claims can be implemented by a single hardware or software module. The appearance of certain technical features in different dependent claims does not mean that these technical features cannot be combined to achieve beneficial effects.

Claims

1. A method for transaction switching based on a multi-service system, applied to a multi-service system, the method comprising: receiving a transaction request, the transaction request comprising at least one transaction sub-request, each transaction sub-request comprising a payer element, a payee element, an account acceptor element, an account element and a transaction resource element, at least one of the account acceptor element, the account element and the transaction resource element being different in different transaction sub-requests in the same transaction request; determining an amount of acceptance resource according to the transaction request, and generating an acceptance request, the acceptance request comprising the payer element, the payee element, the account element and the amount of acceptance resource; sending the acceptance request to an account acceptor indicated by the account acceptor element, so that the account acceptor completes a transaction according to the acceptance request.

2. The method of claim 1, wherein, The transaction request comprises a plurality of transaction sub-requests, each transaction sub-request corresponding to an account type. The determining of the amount of acceptance resource according to the transaction request and the generating of the acceptance request comprise: determining an amount of acceptance resource of a first transaction sub-request according to the first transaction sub-request, and generating the acceptance request corresponding to the first transaction sub-request; in a case where an acceptance response corresponding to the first transaction sub-request is received and a transaction standard resource amount of the first transaction sub-request does not reach a total transaction standard resource amount indicated by the transaction request, determining an amount of acceptance resource of a second transaction sub-request according to the second transaction sub-request, and generating the acceptance request corresponding to the second transaction sub-request, until an acceptance response corresponding to an Nth transaction sub-request is received and a sum of transaction standard resource amounts of the first N transaction sub-requests reaches the total transaction standard resource amount indicated by the transaction request, N being a positive integer greater than or equal to 2. 3.The method of claim 2, further comprising: in a case where the acceptance response corresponding to the Nth transaction sub-request is received and the sum of the transaction standard resource amounts of the first N transaction sub-requests reaches the total transaction standard resource amount indicated by the transaction request, sending a transaction notification to a transaction platform triggering the transaction request; wherein the transaction notification has a sub-transaction identifier and a transaction family identifier, and the transaction family identifier of the transaction notification is the same as a transaction family identifier of the transaction request.

4. The method of claim 1, wherein, The transaction resource element comprises a transaction resource amount, a transaction resource type, a transaction standard resource type and a transaction standard resource conversion ratio. The method further comprises: in a case where the transaction resource type in the transaction sub-request is different from the transaction standard resource type, converting the transaction resource amount in the transaction sub-request into a transaction standard resource amount corresponding to the transaction standard resource type according to the transaction standard resource conversion ratio; and completing the transaction by using a standard resource account of the account acceptor indicated by the account acceptor element in the transaction sub-request and according to the converted transaction standard resource amount.

5. The method of claim 1, wherein, The transaction sub-request has a sub-transaction identifier and a transaction family identifier, the sub-transaction identifiers of different transaction sub-requests are different, and the transaction family identifiers of the transaction sub-requests belonging to the same transaction request are the same.

6. The method of claim 1, wherein, The transaction resource element includes a transaction resource amount, a transaction resource type, a transaction standard resource type, and a transaction standard resource conversion ratio, the multi-service system pre-stores a pre-conversion contract, and the pre-conversion contract includes a pre-transaction standard resource type and a pre-transaction standard resource conversion ratio; The determining of the transaction resource amount according to the transaction request includes: In a case where the transaction resource type in the transaction sub-request is different from the transaction standard resource type and the account acceptor indicated by the account acceptor element in the transaction sub-request has the pre-conversion contract, the transaction resource amount in the transaction request is converted into a pre-transaction standard resource amount corresponding to the pre-transaction standard resource type according to the pre-transaction standard resource conversion ratio; The pre-transaction standard resource amount is converted into a transaction standard resource amount corresponding to the transaction standard resource type in the transaction sub-request, and the converted transaction standard resource amount is determined as the transaction resource amount.

7. The method of claim 1, wherein, The transaction resource element includes a first transaction standard resource type, a first transaction standard resource conversion ratio, a second transaction standard resource type, and a second transaction standard resource conversion ratio; The determining of the transaction resource amount according to the transaction request includes: The transaction resource amount in the transaction sub-request is converted into a first transaction standard resource amount corresponding to the first transaction standard resource type according to the first transaction standard resource conversion ratio; The first transaction standard resource amount is converted into a second transaction standard resource amount corresponding to the second transaction standard resource type according to the second transaction standard resource conversion ratio, and the second transaction standard resource amount is determined as the transaction resource amount.

8. The method of claim 1, before the determining of the transaction resource amount according to the transaction request and the generating of the acceptance request, further comprising: According to the transaction request, calling a verification plug-in corresponding to the account element to verify the transaction indicated by the transaction request; The determining of the transaction resource amount according to the transaction request and the generating of the acceptance request include: In a case where the verification passes, the transaction resource amount is determined according to the transaction request, and the acceptance request is generated.

9. The method of claim 8, wherein The verification plug-in is used to verify one or more of the transaction resource element, the account acceptor element, the payer element, and the payee element; The verification plug-in includes one or more of an authority verification plug-in, a quota verification plug-in, and a risk control verification plug-in.

10. The method of claim 8, wherein, The calling of the verification plug-in corresponding to the account element according to the transaction request to verify the transaction indicated by the transaction request includes: Obtaining standard input data required by the verification plug-in from the transaction request; Calling the verification plug-in and inputting the standard input data into the verification plug-in, so that the verification plug-in outputs verification result standard data based on the standard input data; Obtaining the verification result standard data from the verification plug-in.

11. The method of claim 1, wherein, The transaction request includes a payment request and a return request.

12. The method of claim 1, wherein, The multi-service system is configured with a front-end compatibility system and a back-end compatibility system; The method further includes: In the system transition stage, the pre-compatibility system converts the request sent by the transaction initiator using the original interface into the transaction request; In the system transition stage, the post-compatibility system converts the acceptance request into a request conforming to the original interface requirements of the account acceptor, and sends it to the account acceptor.

13. The method of claim 1, wherein, The transaction request corresponds to one payment order or more than two payment orders; The transaction sub-request in the transaction request includes a set of payee elements or more than two sets of payee elements.

14. The method of any one of claims 1 to 13, wherein, The payer element includes a payer identification, a payer personal information, and a payer supplementary information; The payee element includes a payee identification, a payee order identification, and a payee supplementary information; The account element includes an account type and an account identification; The account acceptor element includes an account acceptor type and an account acceptor identification; The transaction resource element includes a transaction resource amount, a transaction resource unit, a transaction resource type, a transaction standard resource type, and a transaction standard resource conversion ratio.

15. The method of any one of claims 1 to 13, wherein, The transaction sub-request further includes a receiving party element and / or an order element.

16. A transaction switching device based on a multi-service system, applied to a multi-service system, the device comprising: a receiving module configured to receive a transaction request, the transaction request including at least one transaction sub-request, each transaction sub-request including a payer element, a payee element, an account acceptor element, an account element, and a transaction resource element, at least one of the account acceptor element, the account element, and the transaction resource element in different transaction sub-requests in the same transaction request being different; an information processing module configured to determine an acceptance resource amount according to the transaction request, and generate an acceptance request including the payer element, the payee element, the account element, and the acceptance resource amount; a sending module configured to send the acceptance request to an account acceptor indicated by the account acceptor element, so that the account acceptor completes a transaction according to the acceptance request.

17. A transaction brokering device based on a multi-service system, comprising: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the transaction switching method based on a multi-service system according to any one of claims 1 to 15.

18. A computer readable storage medium, the computer readable storage medium storing computer program instructions, the computer program instructions being executed by a processor to implement the transaction switching method based on a multi-service system according to any one of claims 1 to 15.

19. A computer program product, comprising a computer program, the computer program being executed by a processor to implement the transaction switching method based on a multi-service system according to any one of claims 1 to 15.

Images