WO2026016409A1 - 基于多业务系统的交易转接方法、装置、设备及介质 - Google Patents

基于多业务系统的交易转接方法、装置、设备及介质

Info

Publication number
WO2026016409A1
WO2026016409A1 PCT/CN2024/141374 CN2024141374W WO2026016409A1 WO 2026016409 A1 WO2026016409 A1 WO 2026016409A1 CN 2024141374 W CN2024141374 W CN 2024141374W WO 2026016409 A1 WO2026016409 A1 WO 2026016409A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
request
account
sub
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2024/141374
Other languages
English (en)
French (fr)
Inventor
江波
胡小舟
鲍鹏
潘薇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Unionpay Co Ltd
Original Assignee
China Unionpay Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Publication of WO2026016409A1 publication Critical patent/WO2026016409A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems

Definitions

  • the transaction business encompasses various types of transactions, such as card transactions, cardless transactions, barcode transactions, ticket transactions, and points transactions. Each of these requires a switching system to facilitate transactions between different institutions.
  • the core exchange elements differ for each type of transaction, necessitating the development of distinct switching systems.
  • the core exchange element for card transactions is the bank card identifier, while for points transactions it's the points redemption provider's identifier and the user's identifier. Points transactions cannot reuse the switching system used for card transactions, and vice versa.
  • the specialized nature of switching systems makes them incompatible with different types of transactions, hindering the integration of transactions with diverse transaction types.
  • Existing transaction switching systems exhibit poor versatility and compatibility.
  • This application provides a transaction switching method, apparatus, device, and medium based on a multi-service system, which can improve the versatility and compatibility of transaction switching.
  • embodiments of this application provide a transaction switching method based on a multi-business system, applied to a multi-business system.
  • the method includes: receiving 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, wherein at least one of the account acceptor element, account element, and transaction resource element in different transaction sub-requests within the same transaction request is different; determining the acceptance resource quantity according to the transaction request, generating an acceptance request, the acceptance request including the payer element, the payee element, the account element, and the acceptance resource quantity; and sending 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.
  • inventions of this application provide a transaction switching device based on a multi-business system, applied to a multi-business system.
  • the device includes: a receiving module, used 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, wherein at least one of the account acceptor element, account element, and transaction resource element in different transaction sub-requests of the same transaction request is different; an information processing module, used to determine the acceptance resource quantity according to the transaction request and generate an acceptance request, the acceptance request including the payer element, the payee element, the account element, and the acceptance resource quantity; and a sending module, used 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.
  • embodiments of this application provide a transaction switching device based on a multi-service system, including: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the transaction switching method based on the first aspect of the multi-service system.
  • embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the transaction switching method based on a multi-service system as described in the first aspect.
  • embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the transaction switching method based on a multi-service system as described in the first aspect.
  • the multi-service system can receive transaction requests in a standard format. Each transaction request may include at least one transaction sub-request. The format of each transaction sub-request is standardized and uniform.
  • a transaction sub-request may include payer elements, payee elements, account acceptor elements, account elements, and transaction resource elements.
  • the multi-service platform can determine the amount of resources that need to be accepted by the account acceptor for this transaction and generate an acceptance request including the payer elements, the payee elements, the account elements, and the acceptance resource amount, which is then sent to the account acceptor to enable the account acceptor to complete the transaction.
  • the core elements of various types of transaction businesses can be highly abstracted. Furthermore, by using the payer elements, the payee elements, the account elements, and the acceptance resource amount, the core elements that the account acceptor needs to know for various types of transaction businesses can be highly abstracted. This allows the multi-service system to interact with parties involved in various types of transaction businesses through standard message requests, enabling the expression of various types of transaction businesses and improving the universality and compatibility of transaction switching.
  • Figure 1 is a schematic diagram of an example of establishing different switching systems for different services in related technologies
  • Figure 2 is a schematic diagram of an example of a multi-service system provided in an embodiment of this application.
  • FIG. 3 is a flowchart of a transaction transfer method based on a multi-service system provided in an embodiment of this application;
  • Figure 4 is a schematic diagram of an example of a transaction process based on a multi-business system provided in an embodiment of this application;
  • Figure 5 is a schematic diagram of another example of a transaction process based on a multi-business system provided in the embodiments of this application;
  • Figure 6 is a flowchart of a transaction transfer method based on a multi-service system provided in another embodiment of this application;
  • Figure 7 is a schematic diagram of an example of the verification process provided in an embodiment of this application.
  • Figure 8 is a schematic diagram of an example of a risk control verification calling verification plugin provided in an embodiment of this application.
  • Figure 9 is a schematic diagram of another example of a multi-service system provided in the embodiments of this application.
  • Figure 10 is a schematic diagram of the structure of a transaction switching device based on a multi-service system provided in an embodiment of this application;
  • the transaction business encompasses various types of transactions, such as card transactions, cardless transactions, barcode transactions, ticket transactions, and points transactions. All of these require a switching system to facilitate transactions between different institutions.
  • the core exchange elements differ for each type of transaction, necessitating the development of distinct switching systems.
  • the core exchange element for card transactions is the bank card identifier, while for points transactions, it's the identifier of the points redeeming party and the user identifier. Points transactions cannot reuse the switching system of card transactions, and similarly, card transactions cannot reuse the switching system of points transactions.
  • Figure 1 is a schematic diagram of an example of establishing different switching systems for different businesses in related technologies.
  • the acquiring institution needs to interact with the issuing institution through a card-based switching system; in a cardless transaction business scenario, the merchant or acquiring institution needs to access the card-based transaction switching system through cardless transaction switching system A, and then interact with the issuing institution through the card-based transaction switching system; in another cardless transaction business scenario, the payment institution needs to interact with the issuing institution through cardless transaction switching system B, and a network bridge structure can be established between cardless transaction switching system B and card-based transaction switching system; in a barcode transaction business scenario, the acquiring institution needs to interact with the barcode payment institution through a barcode transaction switching system; in a points transaction business scenario, the channel needs to interact with the points issuer through a points transaction switching system; in a ticket transaction business scenario, the channel needs to interact with the ticket issuer through a ticket transaction switching system.
  • This application provides a transaction transfer method, apparatus, device, system, storage medium, and computer program product based on a multi-business system.
  • a multi-business system compatible with multiple transaction businesses is constructed. Any transaction business can be refined into a basic conceptual model of "a user purchasing a certain product from a merchant, and paying the merchant a certain quantity and specific unit of a certain type of resource from the user's account opened at an institution," thus completing the transaction between the transaction initiator and the transaction acceptor.
  • This multi-business system enables the interconnection and interoperability of different types of resources, supports combined transactions of different types of accounts and resources, and allows for the management, maintenance, and use of permissions for different types of businesses.
  • This multi-business system can serve as a transaction transfer system for any transaction business, improving the versatility and compatibility of transaction transfer systems.
  • FIG. 2 is a schematic diagram of an example of the multi-service system provided in this application embodiment.
  • merchants/acquiring institutions 111, payment institutions 112, barcode acquiring institutions 113, and other acquiring institutions 114 can access the unified access terminal 12 through their respective normalized standard interfaces, and then access the multi-service system 13 through the unified access terminal 12.
  • Users 115, as transaction initiators, can access the multi-service system 13 through the digital POS platform 14, which can be a platform used for payment transactions on e-commerce platforms.
  • Card issuing institutions 151, payment institutions 152, points issuers 153, ticket issuers 154, and other resource issuers 155, as account acceptors, can access the unified access terminal 16 through their respective normalized standard interfaces, and then access the multi-service system 13 through the unified access terminal 16.
  • the following describes the transaction switching method, apparatus, equipment, storage medium, and computer program product based on a multi-service system provided in this application.
  • the first aspect of this application provides a transaction switching method based on a multi-service system.
  • This transaction switching method is applied to the multi-service system, meaning it can be executed by the multi-service system.
  • Figure 3 is a flowchart of a transaction switching method based on a multi-service system according to an embodiment of this application. As shown in Figure 3, the transaction switching method based on a multi-service system may include steps S201 to S203.
  • step S201 a transaction request is received.
  • Transaction requests can be initiated by digital POS platforms, merchants/acquiring institutions, payment institutions, barcode acquiring institutions, or other acquiring institutions; there are no limitations on this. However, regardless of which party initiates the transaction request, the message format of the transaction request received by the multi-service system is consistent.
  • a transaction request is used to request a transaction.
  • a transaction request can correspond to a single transaction, but this transaction may include one order or multiple orders; that is, the transaction request may correspond to one payment order or two or more payment orders, thereby achieving the combined payment of multiple orders.
  • a user can use one type of account or a combination of multiple account types for a single transaction.
  • a transaction request may include at least one transaction sub-request. Transaction sub-requests can be divided according to the different account types of the user's account used for the transaction, or according to different orders; there are no limitations on this.
  • Each transaction sub-request may include payer elements, payee elements, account acceptor elements, account elements, and transaction resource elements.
  • Payer elements are used to characterize relevant information about the payer.
  • payer elements may include, but are not limited to, payer identifier, payer personal information, and payer supplementary information.
  • the payer identifier identifies the payer; for example, the payer identifier may include the payer ID.
  • the payer personal information characterizes the payer's personal identity; for example, the payer personal information may include the payer's name.
  • the payer supplementary information may include any additional information about the payer that needs to be supplemented. This information can be set according to specific scenarios and needs; for example, the payer supplementary information may include the payer's location information, which may be Global Positioning System (GPS) information, but is not limited to this.
  • GPS Global Positioning System
  • the payee element is used to represent relevant information about the payee.
  • the payee may include merchants in the transaction.
  • the payee element may include, but is not limited to, payee identifier, payee order identifier, and payee supplementary information.
  • the payee identifier is used to identify the payee; for example, the payee identifier may include the payee ID.
  • the payee order identifier includes the order identifier associated with this payee in this transaction, and the payee order identifier is unique.
  • the payee supplementary information may include other information about the payee that needs to be supplemented, such as the payee's location information, which may be GPS information, but is not limited to this.
  • a transaction sub-request in a transaction request may include one set of payee elements or two or more sets of payee elements.
  • One set of payee elements can represent one payee, and different sets of payee elements can represent different payees. That is, one transaction can correspond to two or more payees, thereby realizing the collection of payments from multiple payees in multi-order payments.
  • the account acceptor element is used to characterize information about the acceptor of the transaction resource.
  • the account acceptor element may include, but is not limited to, account acceptor type and account acceptor identifier.
  • the account acceptor type characterizes the type of account acceptor; for example, it may include issuing bank, payment institution, points issuer, ticket issuer, etc., and is not limited here.
  • the account acceptor identifier identifies the account acceptor; for example, the account acceptor identifier may include account acceptor ID.
  • the account element may include, but is not limited to, account type and account identifier.
  • the account type characterizes the type of account; for example, the account type may include card account, barcode payment account, points account, ticket account, etc.
  • the account identifier identifies the account; for example, the account identifier may include account ID, which corresponds to the account type, and the account ID may be a card number, barcode account ID, points account ID, ticket code, etc.
  • the transaction resource element characterizes the transaction resource.
  • transaction resource elements may include, but are not limited to, transaction resource quantity, transaction resource unit, transaction resource type, transaction standard resource type, and transaction standard resource conversion ratio.
  • transaction resource elements may also include total transaction resource quantity or total transaction standard resource quantity.
  • Transaction resource quantity refers to the number of transaction resources 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 RMB, then the transaction resource unit is yuan.
  • the transaction standard resource type represents the type of transaction resource as a standard, and settlement is generally based on transaction resources of the transaction standard resource type.
  • the transaction standard resource conversion ratio is the conversion rate of transaction resources of the transaction resource type into transaction resources of the transaction
  • a transaction sub-request may also include an acceptor element and/or an order element.
  • the acceptor element is used in transactions with a three-party architecture, which includes a payee, a payer, and an acceptor.
  • the acceptor element is used to identify the acceptor, which may be a third-party payment institution, etc., and is not limited thereto.
  • the acceptor element may include an acceptor identifier, which may include an acceptor ID, and the acceptor element may also include an acceptor type.
  • the order element can be used to identify relevant information about the order, such as the order content.
  • At least one of the account acceptor element, account element, or transaction resource element differs in different transaction sub-requests.
  • the transaction request may be a request for a combination of transactions involving multiple types of resources. That is, a multi-business system can support combined transactions using multiple types of resources such as payment cards, third-party payment accounts, points, and tickets.
  • the account acceptor element, account element, and transaction resource element in different transaction sub-requests of the transaction request may differ.
  • a transaction request includes three sub-requests: the first sub-request uses a payment card, the second uses a third-party payment account, and the third uses points
  • the account acceptor element indicates the payment card issuer
  • the account element indicates the payment card itself
  • the transaction resource element indicates the amount as the payment resource type.
  • the account acceptor element indicates the third-party payment institution
  • the account element indicates the third-party payment account
  • the transaction resource element indicates the amount as the payment resource type.
  • the account acceptor element indicates the points issuer
  • the account element indicates the points account
  • the transaction resource element indicates the points as the payment resource type.
  • the transaction resource type and quantity in the transaction resource element of the sub-request can be determined based on the input of the user who triggered the transaction request; that is, the user can choose the type and quantity of resources used in the transaction.
  • transaction requests are standardized, enabling multiple business systems to complete transaction transfers based on transaction requests in the same standard format under different business scenarios.
  • a transaction request may include a payment request and a return request.
  • the executed transaction is a payment transaction.
  • the transaction request is a return request
  • the executed transaction is a return transaction.
  • the transaction transfer method based on a multi-service system in this application embodiment can support partial or full returns within a single transaction.
  • step S202 the amount of acceptance resources is determined based on the transaction request, and an acceptance request is generated.
  • the acceptance resource quantity refers to the amount of resources of the transaction resource type corresponding to the account acceptor element in this transaction. If the transaction resource type in the transaction resource element of the transaction request corresponds to the account acceptor type in the account acceptor element, the transaction resource quantity in the transaction resource element of the transaction request can be determined as the acceptance resource quantity. If the transaction resource type in the transaction resource element of the transaction request does not correspond to the account acceptor type in the account acceptor element, the transaction resource quantity in the transaction resource element of the transaction request can be converted into the amount of transaction resources corresponding to the account acceptor type in the account acceptor element, and the converted amount of transaction resources corresponding to the account acceptor type is determined as the acceptance resource quantity.
  • An acceptance request may include payer elements, payee elements, account elements, and acceptance resource quantity; for details, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.
  • the account acceptor Upon receiving an acceptance request, the account acceptor can identify the payer, payee, accounts involved in the transaction, and the amount of resources to be accepted. Based on these details, the account acceptor completes the acceptance. After completing the acceptance, the account acceptor can also send an acceptance response to the multi-business system. The multi-business system, based on the response, can determine whether the acceptance was successful or failed, facilitating subsequent settlement.
  • a transaction sub-request has a sub-transaction identifier and a transaction family identifier. Different transaction sub-requests have different sub-transaction identifiers, while transaction sub-requests belonging to the same transaction request have the same transaction family identifier.
  • 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 each 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. Transaction sub-requests with the same transaction family identifier belong to the same transaction. After receiving the acceptance response to the acceptance request corresponding to each transaction sub-request, the multi-service system can record the sub-transaction identifier and transaction family identifier of that transaction sub-request to record this sub-transaction.
  • acceptance requests are standardized, enabling multiple business systems to complete transaction transfers based on the same standard format acceptance requests across different business scenarios.
  • the standardized transaction and acceptance requests allow multiple business systems to access various types of transaction parties and facilitate the transfer of various transaction types.
  • the multi-service system can receive transaction requests in a standard format.
  • Each transaction request may include at least one transaction sub-request.
  • the format of each sub-request is standardized and uniform.
  • a sub-request may include payer elements, payee elements, account acceptor elements, account elements, and transaction resource elements.
  • the multi-service platform can determine the amount of resources that need to be accepted by the account acceptor for this transaction and generate an acceptance request including the payer elements, the payee elements, the account elements, and the accepted resource amount, which is then sent to the account acceptor to enable the account acceptor to complete the transaction.
  • the payer elements, payee elements, account acceptor elements, account elements, and transaction resource elements the core elements of various types of transaction businesses can be highly abstracted.
  • the core elements that the account acceptor needs to know for various types of transaction businesses can be highly abstracted. This allows the multi-service system to interact with parties involved in various types of transaction businesses through standard message requests, enabling the expression of various types of transaction businesses and improving the universality and compatibility of transaction transfers.
  • non-monetary resources such as points and tickets
  • These non-monetary resources can be converted into monetary resources for settlement based on transaction resource elements, ensuring transaction redemption and settlement.
  • it also enables the conversion from non-monetary to other non-monetary resources, and from monetary to other monetary resources, achieving the network circulation of heterogeneous resources and the trading circulation of resources of various standard types.
  • the transaction transfer method based on multi-business systems in this application embodiment can also realize combined payment of heterogeneous resources, merged payment of multiple orders, and separate settlement of easily purchased resources, improving the flexibility and scalability of the system processing for transaction business.
  • a transaction request includes multiple transaction sub-requests, each transaction sub-request corresponding to an account type, and one acceptance request corresponding to one transaction sub-request.
  • Step S202 can be further refined as follows: based on the first transaction sub-request, determine the acceptance resource amount of the first transaction sub-request and generate the acceptance request corresponding to the first transaction sub-request; if an acceptance response is received corresponding to the first transaction sub-request and the transaction standard resource amount of the first transaction sub-request does not reach the total transaction standard resource amount indicated by the transaction request, based on the second transaction sub-request, determine the acceptance resource amount of the second transaction sub-request and generate the acceptance request corresponding to the second transaction sub-request, until an acceptance response is received 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, where N is a positive integer greater than
  • the multi-service system can receive the sub-requests sequentially, processing one sub-request before moving on to the next.
  • the multi-service system receives the first sub-request, determines its acceptance resource quantity based on it, generates a first acceptance request, and sends it to the account acceptor indicated by the first sub-request.
  • the account acceptor processed the acceptance according to the request and sends a first acceptance response back to the multi-service system, indicating successful acceptance.
  • the multi-service system determines whether the accepted standard resource quantity has reached the total standard resource quantity for this transaction.
  • the second sub-request determines its acceptance resource quantity based on it, generates a second acceptance request, and sends it to the account acceptor indicated by the second sub-request. This process continues until the account acceptor indicated by the Nth transaction sub-request responds with an acceptance reply, and the amount of standard resources already accepted reaches the total amount of standard resources for this transaction. At that point, no further transaction sub-requests in this transaction request will be accepted.
  • the transaction request is triggered by the trading platform, which can be an e-commerce platform, but is not limited to this.
  • the multi-service system receives the acceptance response corresponding to the Nth transaction sub-request and the sum of the standard resource amounts of the previous N transaction sub-requests reaches the total standard resource amount indicated by the transaction request, it sends a transaction notification to the trading platform that triggered the transaction request.
  • the transaction notification is used to inform the trading platform that the transaction has been successful.
  • 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+1)th sub-transaction in the transaction indicated by the transaction request, but this (N+1)th sub-transaction is mainly used to notify the trading platform so that the trading platform can align information with the multi-service platform, and does not generate new resource deductions.
  • the sub-transactions corresponding to the N sub-transaction requests and the (N+1)th sub-transaction corresponding to the transaction notification can be associated through the transaction family identifier.
  • the multi-service system records the transaction family identifier and sub-transaction identifier of these N+1 sub-transactions to facilitate subsequent settlement through the transaction family identifier.
  • FIG. 4 is a schematic diagram of an example of a transaction process based on a multi-service system provided in this application embodiment.
  • the user selects a payment card, a third-party payment account, and communication points to complete a payment of 200 yuan.
  • the transaction process may include steps a1 to a24.
  • step a1 the user initiates a payment order with the trading platform.
  • the total amount of the payment order is 200 yuan.
  • step a2 the transaction platform invokes the digital POS platform.
  • step a3 the user enters the payment amount from their payment card into the digital POS platform.
  • the payment amount is 50 yuan.
  • step a4 the digital POS platform sends the first transaction sub-request to the multi-business system.
  • the account acceptor element indicates that the account acceptor is the issuing bank of the payment card
  • the account element indicates that the account is the payment card
  • the transaction resource element indicates that the total transaction standard resource amount is 200 yuan
  • the transaction resource amount of this sub-transaction is 50 yuan
  • the transaction resource type and transaction standard resource type are RMB
  • the transaction standard resource conversion ratio is 1:1.
  • step a5 the multi-service system sends the first acceptance request to the issuing bank of the payment card based on the first transaction sub-request.
  • the acceptance resource amount in the acceptance request is 50 yuan.
  • step a6 the multi-service system receives an acceptance response from the issuing bank of the payment card.
  • the acceptance response indicates successful acceptance.
  • step a7 the multi-service system records the sub-transaction identifier TransId1 and the transaction family identifier TransFamilyId of the first sub-transaction.
  • step a8 the multi-service system sends a transaction response to the digital POS platform.
  • the transaction response indicates that the amount to be paid for this transaction is 150 yuan.
  • step a9 the user enters the payment amount from their third-party payment account into the digital POS platform.
  • the payment amount from the third-party payment account is 90 yuan.
  • the digital POS platform sends a second transaction sub-request to the multi-business system.
  • the account acceptor element indicates that the account acceptor is a third-party payment institution
  • the account element indicates that the account is a third-party payment account
  • the transaction resource element indicates that the total transaction standard resource amount is 200 yuan
  • the transaction resource quantity of this sub-transaction is 90 yuan
  • the transaction resource type and transaction standard resource type are RMB
  • the transaction standard resource conversion ratio is 1:1.
  • step a11 the multi-service system sends a second acceptance request to the issuing bank of the payment card based on the second transaction sub-request.
  • the acceptance resource amount in the acceptance request is 90 yuan.
  • step a12 the multi-service system receives an acceptance response from the issuing bank of the payment card.
  • the acceptance response indicates successful acceptance.
  • step a13 the multi-service system records the sub-transaction identifier TransId2 and the transaction family identifier TransFamilyId of the second sub-transaction.
  • step a14 the multi-service system sends a transaction response to the digital POS platform.
  • the transaction response indicates that the amount to be paid for this transaction is 60 yuan.
  • step a15 the user enters the amount of points to pay into the digital POS platform.
  • the payment points amount is 6000
  • the point-to-amount conversion ratio is 100:1
  • the payment amount corresponding to 6000 points is 60 yuan.
  • step a16 the digital POS platform sends a third transaction sub-request to the multi-business system.
  • the account acceptor element indicates that the account acceptor is the issuer of communication points
  • the account element indicates that the account is a points account
  • the transaction resource element indicates that the total amount of standard resources for the transaction is 200 yuan
  • the transaction resource quantity for this sub-transaction is 6000 points
  • the transaction resource type and standard resource type are RMB
  • the transaction resource conversion ratio is 100:1.
  • step a17 the multi-service system sends the first acceptance request to the issuing bank of the payment card based on the third transaction sub-request.
  • the acceptance resource amount in the acceptance request is 6000 points.
  • step a18 the multi-service system receives an acceptance response from the communication points issuer.
  • the acceptance response indicates successful acceptance.
  • step a19 the multi-service system records the sub-transaction identifier TransId3 and the transaction family identifier TransFamilyId of the third sub-transaction.
  • step a20 the multi-service system sends a transaction response to the digital POS platform. Based on the conversion ratio between points and amount, the multi-service system converts the points into amount, obtaining a payment amount of 60 yuan for the third sub-transaction. The system calculates the outstanding payment amount for this transaction to be 0 yuan, and the transaction response indicates that the outstanding payment amount for this transaction is 0 yuan.
  • step a21 the multi-service system sends a transaction notification to the transaction platform.
  • the transaction notification indicates that the amount to be paid for this transaction is 0 yuan, and 200 yuan has already been paid.
  • 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 here, the notification to the transaction platform is considered the fourth sub-transaction, but the fourth sub-transaction only serves as a notification to facilitate settlement for the transaction platform and does not generate a new payment amount.
  • step a23 the trading platform sends a transaction notification response to the multi-business system.
  • step a24 the multi-service system sends a transaction completion notification to the digital POS platform.
  • the transaction completion notification indicates that the transaction has been completed.
  • Transaction resource elements include transaction resource quantity, transaction resource type, standard transaction resource type, and standard transaction resource conversion ratio.
  • the account acceptor in the cross-border transaction can pre-sign a pre-conversion contract with a multi-business system.
  • This pre-stored pre-conversion contract can include the pre-transaction standard resource type and the pre-transaction standard resource conversion ratio.
  • the pre-transaction standard resource type is the same as the intermediate conversion resource type, and the pre-transaction standard resource conversion ratio is the same as the intermediate conversion resource conversion ratio.
  • the transaction resource elements in the transaction sub-request include the transaction resource quantity, transaction resource type, transaction standard resource type, and transaction standard resource conversion ratio.
  • the bank in country A1 can pre-sign a pre-conversion contract with the multi-service platform.
  • the pre-transaction standard resource type in the pre-conversion contract is the transaction standard resource type of country A1
  • the pre-transaction standard resource conversion ratio in the pre-conversion contract is the conversion ratio of bank points in country A1 to transaction resources of the transaction standard resource type in country A1.
  • the multi-service system can then convert the bank points in country A1 into the transaction standard resource quantity of the transaction standard resource type in country A1 according to the pre-transaction standard resource, then convert the transaction standard resource quantity of the transaction standard resource type in country A1 into the transaction standard resource quantity of the transaction standard resource type in country A2, and determine the transaction standard resource quantity of the transaction standard resource type in country A2 as the acceptance resource quantity to generate an acceptance request.
  • the multi-service system can also realize the conversion of transaction resources of two transaction resource types through transaction resources of another transaction resource type.
  • Transaction resource elements may 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
  • the second transaction standard resource type corresponds to the second transaction standard resource conversion ratio.
  • Step S202 can be further refined as follows: according to the first transaction standard resource conversion ratio, the transaction resource quantity in the transaction sub-request is converted into a first transaction standard resource quantity corresponding to the first transaction standard resource type; according to the second transaction standard resource conversion ratio, the first transaction standard resource quantity is converted into a second transaction standard resource quantity corresponding to the second transaction standard resource type, and the second transaction standard resource quantity is determined as the acceptance resource quantity, generating an acceptance request.
  • step b2 the third-party payment institution sends a transaction request to the multi-business system.
  • This transaction request is used to request the redemption of 100 bank points into airline miles.
  • step b3 the multi-service system sends a transfer acceptance request to the points-issuing bank.
  • the transfer acceptance request is used to request the transfer of 100 bank points from the user's bank points account.
  • the bank is the payer.
  • step b5 the multi-business system performs the conversion of transaction resources.
  • the first standard transaction resource type is RMB
  • the conversion ratio is 100:1, that is, 100 bank points can be converted into 1 RMB.
  • the second standard transaction resource type is mileage, and the conversion ratio is 1:500, that is, 1 RMB can be converted into 500 miles.
  • step b6 the multi-service system sends a transfer-in acceptance request to the airline.
  • the transfer-in acceptance response requests that the converted 500 miles be transferred to the user's account with the airline.
  • the airline is the recipient.
  • step b7 the airline sends a transfer acceptance response to the multi-service system.
  • the transfer acceptance response indicates that the mileage transfer was successful.
  • step b8 the multi-service system sends a transaction response to the third-party payment institution.
  • the transaction response indicates that the transaction was successful.
  • step b9 the third-party payment structure displays the successful transaction result to the user.
  • the transaction upon receiving a transaction request, the transaction can be verified first. Only after successful verification can the subsequent transaction process proceed.
  • Various verification functions can be implemented through flexible verification plugins, comprehensively managing multiple aspects such as resource liquidity, account acceptance liquidity, payer liquidity, and payee liquidity to ensure transaction security.
  • Verification plugins use standardized input and output parameters, and their invocation is also standardized.
  • the updated functions can be implemented by adding new plugins. Adding new plugins will not affect the original business logic, allowing for flexible expansion of transaction services through plug-and-play plugins.
  • Figure 6 is a flowchart of a transaction switching method based on a multi-service system provided in another embodiment of this application.
  • the difference between Figure 6 and Figure 3 is that the transaction switching method based on a multi-service system shown in Figure 6 may also include step S204, and step S202 in Figure 3 may be further refined into step S2021 shown in Figure 6.
  • step S204 based on the transaction request, the verification plugin corresponding to the account element is invoked to verify the transaction indicated by the transaction request.
  • Different account elements included in the transaction sub-requests within a transaction request will require different verification plugins.
  • the appropriate verification plugin can be determined based on the account elements included in the transaction sub-requests within the transaction request, and then invoked to perform verification of the transaction indicated by the transaction request.
  • verification plugins can be used to verify one or more of the following: transaction resource elements, account acceptor elements, payer elements, and payee elements.
  • Verification plugins include one or more of the following: permission verification plugins, credit limit verification plugins, and risk control verification plugins.
  • Permission verification plugins may further include transaction resource permission verification plugins, account acceptor permission verification plugins, payer permission verification plugins, and payee permission verification plugins, etc.
  • Credit limit verification plugins may further include transaction resource credit limit verification plugins, account acceptor credit limit verification plugins, payer credit limit verification plugins, and payee credit limit verification plugins, etc.
  • Risk control verification plugins may further include transaction resource risk control verification plugins, account acceptor risk control verification plugins, payer risk control verification plugins, and payee risk control verification plugins, etc.
  • FIG 7 is a schematic diagram of an example of the verification process provided in this application embodiment.
  • Permission verification may include permission verification for the circulation of transaction resources, permission verification for the circulation of account acceptors, permission verification for the circulation of payers, and permission verification for the circulation of payees.
  • Permission verification for the circulation of transaction resources can verify the access permission of transaction resources according to pre-set transaction resource switches, transaction resource whitelists, transaction resource blacklists, etc., that is, verify whether the transaction resource is allowed to circulate in the transaction business.
  • Permission verification for the circulation of account acceptors can verify the permissions of account acceptors according to pre-set hierarchical rules.
  • the hierarchical rules can be set according to account acceptors, the acceptance limit of account acceptors, the whitelist of account acceptors, the whitelist of transactions that account acceptors can participate in, etc.
  • Permission verification for the circulation of payers can be performed according to pre-set whitelists, yellow lists, blacklists, etc.
  • Permission verification for the circulation of payees can be performed according to pre-set whitelists, yellow lists, blacklists, etc.
  • credit limit verification can include verification of the credit limit for transaction resource circulation, the credit limit for account acceptors, the credit limit for payers, and the credit limit for payees.
  • Credit limit verification is similar to the permission verification methods described above, except that it focuses on the credit limit itself and can verify the credit limits of transaction resources, account acceptors, payers, and payees according to pre-set credit limit rules.
  • Risk control verification can include risk control verification of transaction resource circulation, risk verification of account acceptors, risk verification of payers, and risk verification of payees.
  • Risk control verification is similar to the permission verification methods described above, except that it focuses on risk control and can verify the risk control of transaction resources, account acceptors, payers, and payees according to pre-set risk rules, risk whitelists, risk yellowlists, and risk blacklists.
  • Transaction security is enhanced by verifying transaction resources, account acceptors, payers, and payees. Furthermore, the verification rules set within the plugin allow for flexible configuration and efficient verification.
  • the input and output data of the verification plugin are unified and standardized.
  • the verification plugin can process the standardized input data to obtain the verification result.
  • the multi-service system can obtain the standard input data required by the verification plugin from the transaction request; call the verification plugin to input the standard input data, so that the verification plugin outputs standard verification result data based on the standard input data; and obtain the standard verification result data from the verification plugin.
  • the standard input data may include the payer account identifier, transaction resource quantity, transaction resource type, payee identifier, and verification type.
  • the verification type corresponds to the account type indicated by the account element. In some examples, the verification type can be directly assigned the account type.
  • the standard verification result data includes the verification result.
  • FIG 8 is a schematic diagram of an example of a risk control verification calling verification plugin provided in an embodiment of this application.
  • the verification plugins that can be called for risk control verification may include a payment card risk verification plugin, a points risk verification plugin, and other verification plugins.
  • Each verification plugin can be pre-registered in the plugin registry center.
  • Multi-business systems can pre-subscribe to the verification plugins that need to be called from the plugin registry center, and call the corresponding plugin when needed. For example, if the account indicated by the account element is a payment card, the payment card risk verification plugin is called; if the account indicated by the account element is a points account, the points risk verification plugin is called.
  • the standard input data of the verification plugin may include the payer account identifier PayerAcctId, transaction resource amount TrxTmt, transaction resource type currency, payee identifier merchantNO, and verification type serviceGroup.
  • the standard data of the verification result of the verification plugin may include the risk score.
  • step S2021 if the verification passes, the amount of acceptance resources is determined based on the transaction request, and an acceptance request is generated.
  • functions other than verification in the multi-business system can also be implemented through plugins.
  • functions such as transaction resource conversion and clearing can be implemented as plugins.
  • This application embodiment can support pluginization of various access parties at the levels of access, permissions, quotas, risk control, and operation management. Each plugin can be dynamically loaded and unloaded. New functional logic implemented through plugins will not affect the original business functional logic, making the implementation of transaction business more flexible.
  • the front-end compatibility system converts requests sent from the access party's original interface into transaction requests that conform to the requirements of the multi-service system.
  • the back-end compatibility system converts acceptance requests output by the multi-service system into requests that conform to the access party's original interface.
  • Access parties may include transaction initiators and account acceptors. Transaction initiators may include users, third-party payment institutions, transaction platforms, digital POS platforms, acquiring institutions, etc.
  • Figure 9 is a schematic diagram of another example of the multi-service system provided in the embodiments of this application.
  • the difference between Figure 9 and Figure 2 is that the multi-service system 13 shown in Figure 9 is also configured with a front-end compatibility system 17 and a back-end compatibility system 18.
  • Merchants/acquiring institutions 111, payment institutions 112, barcode acquiring institutions 113 and other acquiring institutions 114 can access the unified access terminal 12 through the normalized standard interface.
  • Card issuers 151, payment institutions 152, points issuers 153, ticket issuers 154 and other resource issuers 155 can access the unified access terminal 16 through the normalized standard interface.
  • Card issuers 151, payment institutions 152, points issuers 153, ticket issuers 154 and other resource issuers 155 can access the back-end compatibility system 18 through the original interface.
  • a second aspect of this application provides a transaction switching device based on a multi-service system, which is applied to a multi-service system.
  • Figure 10 is a schematic diagram of the structure of a transaction switching device based on a multi-service system provided in an embodiment of this application.
  • the transaction switching device 300 based on a multi-service system may include a receiving module 301, an information processing module 302, and a sending module 303.
  • the receiving module 301 can be used to receive transaction requests.
  • a transaction request includes at least one transaction sub-request.
  • Each transaction sub-request includes payer elements, payee elements, account acceptor elements, account elements, and transaction resource elements. At least one of the account acceptor elements, account elements, and transaction resource elements may differ in different transaction sub-requests within the same transaction request.
  • the information processing module 302 can be used to determine the amount of accepted resources and generate an acceptance request based on the transaction request.
  • An acceptance request includes payer information, payee information, account information, and acceptance amount.
  • the sending module 303 can be used to send an acceptance request to the account acceptor indicated by the account acceptor element, so that the account acceptor can complete the transaction according to the acceptance request.
  • a transaction request includes multiple transaction sub-requests, each corresponding to an account type.
  • the information processing module 302 can be specifically configured to: determine the acceptance resource quantity of the first transaction sub-request based on the first transaction sub-request, and generate an acceptance request corresponding to the first transaction sub-request; if an acceptance response corresponding to the first transaction sub-request is received and the transaction standard resource quantity of the first transaction sub-request does not reach the total transaction standard resource quantity indicated by the transaction request, determine the acceptance resource quantity of the second transaction sub-request based on the second transaction sub-request, and generate an acceptance request corresponding to the second transaction sub-request, until an acceptance response corresponding to the Nth transaction sub-request is received and the sum of the transaction standard resource quantities of the first N transaction sub-requests reaches the total transaction standard resource quantity indicated by the transaction request, where N is a positive integer greater than or equal to 2.
  • the information processing module 302 can also be used to: send a transaction notification to the trading platform that triggered the transaction request when it 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 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 resource elements include transaction resource quantity, transaction resource type, transaction standard resource type, and transaction standard resource conversion ratio.
  • the information processing module 302 can also be used to: when the transaction resource type in the transaction sub-request differs from the transaction standard resource type, convert the transaction resource quantity in the transaction sub-request into a transaction standard resource quantity corresponding to the transaction standard resource type according to the transaction standard resource conversion ratio; and complete the transaction using the pre-set standard resource account of the account acceptor indicated by the account acceptor element in the transaction sub-request, based on the converted transaction standard resource quantity.
  • a transaction sub-request has a sub-transaction identifier and a transaction family identifier. Different transaction sub-requests have different sub-transaction identifiers, while transaction sub-requests belonging to the same transaction request have the same transaction family identifier.
  • the transaction resource elements include the transaction resource quantity, transaction resource type, transaction standard resource type, and transaction standard resource conversion ratio.
  • the multi-business system pre-stores a pre-conversion contract, which includes a pre-transaction standard resource type and a pre-transaction standard resource conversion ratio.
  • Information processing module 302 can be specifically used to: when 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 quantity in the transaction request into the pre-transaction standard resource quantity corresponding to the pre-transaction standard resource type according to the pre-transaction standard resource conversion ratio; convert the pre-transaction standard resource quantity into the transaction standard resource quantity corresponding to the transaction standard resource type in the transaction sub-request, and determine the converted transaction standard resource quantity as the acceptance resource quantity.
  • the transaction resource elements 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 information processing module 302 can be specifically configured to: convert the transaction resource quantity in the transaction sub-request into a first transaction standard resource quantity corresponding to the first transaction standard resource type according to the first transaction standard resource conversion ratio; convert the first transaction standard resource quantity into a second transaction standard resource quantity corresponding to the second transaction standard resource type according to the second transaction standard resource conversion ratio; and determine the second transaction standard resource quantity as the acceptance resource quantity.
  • the transaction switching device 300 based on a multi-service system may further include a verification module.
  • the verification module can be used to: invoke a verification plugin corresponding to the account elements according to the transaction request, and verify the transaction indicated by the transaction request.
  • the information processing module 302 can be specifically used to: determine the amount of acceptance resources and generate an acceptance request based on the transaction request, provided that the verification is successful.
  • the verification plugin is used to verify one or more of the following elements: transaction resource elements, account acceptor elements, payer elements, and payee elements.
  • Verification plugins include one or more of the following: permission verification plugins, credit limit verification plugins, and risk control inspection plugins.
  • the validation module may be specifically used to: obtain the standard input data required by the validation plugin from the transaction request; invoke the validation plugin, input the standard input data into the validation plugin, so that the validation plugin outputs validation result standard data based on the standard input data; and obtain the validation result standard data from the validation plugin.
  • transaction requests include payment requests and return requests.
  • the multi-service system is configured with a front-end compatible system and a back-end compatible system.
  • the transaction switching device 300 of the multi-service system further includes a conversion module, which can be used to: convert a request sent by a transaction initiator using the original interface into a transaction request through the front-end compatible system during the system transition phase; and convert an acceptance request into a request that conforms to the original interface requirements of the account acceptor through the back-end compatible system during the system transition phase, and send it to the account acceptor.
  • a transaction request corresponds to one or more payment orders.
  • Transaction sub-requests within a transaction request may include one or more sets of payee elements.
  • the payer element includes payer identifier, payer personal information, and payer supplementary information.
  • the payee elements include payee identifier, payee order identifier, and payee supplementary information.
  • Account elements include account type and account identifier.
  • the elements of a transaction resource include the quantity of the transaction resource, the unit of the transaction resource, the type of the transaction resource, the type of the standard transaction resource, and the conversion ratio of the standard transaction resource.
  • the transaction sub-request also includes acceptor elements and/or order elements.
  • 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. All implementation methods in the above method embodiments are applicable to the embodiments of this device and can achieve the same technical effect.
  • Memory 401 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical/tangible memory storage device. Therefore, typically, 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 the operations described with reference to the transaction switching method based on a multi-service system according to embodiments of this application.
  • ROM read-only memory
  • RAM random access memory
  • disk storage media device e.g., optical storage media device
  • flash memory device electrical, optical, or other physical/tangible memory storage device. Therefore, typically, 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),
  • the processor 402 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 401, so as to implement the transaction transfer method based on the multi-service system in the above embodiments.
  • the transaction switching device 400 based on a multi-service system may also include a communication interface 403 and a bus 404. As shown in Figure 11, the memory 401, processor 402, and communication interface 403 are connected through the bus 404 and communicate with each other.
  • the communication interface 403 is mainly used to realize communication between various modules, devices, units and/or equipment in the embodiments of this application. Input devices and/or output devices can also be connected through the communication interface 403.
  • Bus 404 couples the components of transaction switching device 400 based on a multi-service system together.
  • bus 404 may include 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 Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, etc.
  • AGP Accelerated Graphics Port
  • EISA Enhanced Industry Standard Architecture
  • FFB Front Side Bus
  • HT Hyper Transport
  • ISA Industry Standard Architecture
  • ISA Industry Standard Architecture
  • LPC Low Pin Count
  • the bus may be 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 Bus (VLB) bus, or other suitable buses, or a combination of two or more of these.
  • MCA Micro Channel Architecture
  • PCI Peripheral Component Interconnect
  • PCI-E PCI-Express
  • SATA Serial Advanced Technology Attachment
  • VLB Video Electronics Standards Association Local Bus
  • a fourth aspect of this application provides a computer-readable storage medium storing computer program instructions. When executed by a processor, these instructions implement the transaction switching method based on a multi-service system described in the above embodiments and achieve the same technical effect. To avoid repetition, further details are omitted here.
  • the aforementioned computer-readable storage medium may include non-transitory computer-readable storage media, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, etc., and is not limited thereto.
  • the fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the transaction transfer method based on a multi-service system as described in the above embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请公开了一种基于多业务系统的交易转接方法、装置、设备及介质，属于交易支付领域。该方法包括：接收交易请求，交易请求包括至少一个交易子请求，每个交易子请求包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素，同一交易请求中不同的交易子请求中的账户承兑方要素、账户要素、交易资源要素中至少一者不同；根据交易请求，确定承兑资源量，生成承兑请求，承兑请求包括付款方要素、收款方要素、账户要素和承兑资源量；向账户承兑方要素指示的账户承兑方发送承兑请求，以使账户承兑方根据承兑请求完成交易。

Description

基于多业务系统的交易转接方法、装置、设备及介质
相关申请的交叉引用
本申请要求享有于2024年7月15日提交的名称为“基于多业务系统的交易转接方法、装置、设备及介质”的中国专利申请202410947068.4的优先权，该申请的全部内容通过引用并入本文中。
技术领域
本申请属于交易支付领域，尤其涉及一种基于多业务系统的交易转接方法、装置、设备及介质。
背景技术
在交易业务领域中存在各种各样的业务，例如，有卡交易业务、无卡交易业务、条码交易业务、票券交易业务、积分交易业务等，在上述业务中均需建立转接系统，以建立一些机构与另一些机构之间的业务转接。而不同的业务的核心交换要素不同，使得不同的业务需要对应建立不同的转接系统，例如，有卡交易业务的核心交换要素为银行卡标识，积分交易业务的核心交换要素为积分承兑方标识和用户标识，积分交易业务无法复用有卡交易业务的转接系统，同理，有卡交易业务业无法复用积分交易业务的转接系统。转接系统的专用性使得其无法兼容不同类型的交易业务，更难以实现具有不同类型的交易业务的融合业务。现有的交易转接系统的通用性和兼容性都较差。
发明内容
本申请实施例提供一种基于多业务系统的交易转接方法、装置、设备及介质，能够提高交易转接的通用性和兼容性。
第一方面，本申请实施例提供一种基于多业务系统的交易转接方法，应用于多业务系统，该方法包括：接收交易请求，交易请求包括至少一个交易子请求，每个交易子请求包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素，同一交易请求中不同的交易子请求中的账户承兑方要素、账户要素、交易资源要素中至少一者不同；根据交易请求，确定承兑资源量，生成承兑请求，承兑请求包括付款方要素、收款方要素、账户要素和承兑资源量；向账户承兑方要素指示的账户承兑方发送承兑请求，以使账户承兑方根据承兑请求完成交易。
第二方面，本申请实施例提供一种基于多业务系统的交易转接装置，应用于多业务系统，该装置包括：接收模块，用于接收交易请求，交易请求包括至少一个交易子请求，每个交易子请求包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素，同一交易请求中不同的交易子请求中的账户承兑方要素、账户要素、交易资源要素中至少一者不同；信息处理模块，用于根据交易请求，确定承兑资源量，生成承兑请求，承兑请求包括付款方要素、收款方要素、账户要素和承兑资源量；发送模块，用于向账户承兑方要素指示的账户承兑方发送承兑请求，以使账户承兑方根据承兑请求完成交易。
第三方面，本申请实施例提供一种基于多业务系统的交易转接设备，包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面的基于多业务系统的交易转接方法。
第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现第一方面的基于多业务系统的交易转接方法。
第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现第一方面的基于多业务系统的交易转接方法。
本申请实施例提供一种基于多业务系统的交易转接方法、装置、设备及介质，多业务系统可接收标准格式的交易请求，交易请求可包括至少一个交易子请求，交易子请求的格式统一标准化，交易子请求可包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素，多业务平台根据交易请求可确定本次交易需要与账户承兑方承兑的资源量，并生成包括付款方要素、所述收款方要素、所述账户要素和承兑资源量的承兑请求发送给账户承兑方，以使账户承兑方完成交易。通过付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素可将各种类型的交易业务的核心要素高度抽象出来，以及，通过付款方要素、所述收款方要素、所述账户要素和承兑资源量可将各种类型的交易业务需要账户承兑方得知的核心要素高度抽象出来，实现多业务系统与各种类型的交易业务的交易方都可通过标准的报文请求进行交互，实现各种类型的交易业务的业务表达，提高了交易转接的通用性和兼容性。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为相关技术中不同业务对应建立不同的转接系统的一示例的示意图；
图2为本申请实施例提供的多业务系统的一示例的示意图；
图3为本申请一实施例提供的基于多业务系统的交易转接方法的流程图；
图4为本申请实施例提供的基于多业务系统的交易流程的一示例的示意图；
图5为本申请实施例提供的基于多业务系统的交易流程的另一示例的示意图；
图6为本申请另一实施例提供的基于多业务系统的交易转接方法的流程图；
图7为本申请实施例提供的校验流程的一示例的示意图；
图8为本申请实施例提供的风险控制校验调用校验插件的一示例的示意图；
图9为本申请实施例提供的多业务系统的另一示例的示意图；
图10为本申请一实施例提供的基于多业务系统的交易转接装置的结构示意图；
图11为本申请一实施例提供的基于多业务系统的交易转接设备的结构示意图。
具体实施方式
下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。需要说明的是，本申请实施例中对信息、数据的获取、存储、使用、处理等均得到用户或相关机构的授权，符合国家法律法规的相关规定。
在交易业务领域中存在各种各样的业务，例如，有卡交易业务、无卡交易业务、条码交易业务、票券交易业务、积分交易业务等，在上述业务中均需建立转接系统，以建立一些机构与另一些机构之间的业务转接。而不同的业务的核心交换要素不同，使得不同的业务需要对应建立不同的转接系统。例如，有卡交易业务的核心交换要素为银行卡标识，积分交易业务的核心交换要素为积分承兑方标识和用户标识，积分交易业务无法复用有卡交易业务的转接系统，同理，有卡交易业务业无法复用积分交易业务的转接系统。图1为相关技术中不同业务对应建立不同的转接系统的一示例的示意图，如图1所示，有卡交易业务场景中，收单机构需要通过有卡转接系统与发卡机构进行交互；一类无卡交易业务场景中，商户或收单机构需要通过无卡交易转接系统A接入有卡交易转接系统，再通过有卡交易转接系统与发卡机构进行交互；另一类无卡交易业务场景中，支付机构需要通过无卡交易转接系统B与发卡机构交互，可在无卡交易转接系统B与有卡交易转接系统之间建立网络桥接结构；条码交易业务场景中，收单结构需要通过条码交易转接系统与条码支付机构交互；积分交易业务场景中，渠道方需要通过积分交易转接系统与积分的发行方交互；票券交易业务场景中，渠道方需要通过票券交易转接系统与票券的发行方交互。由此可见，不同交易业务的转接系统具有专用性，转接系统的专用性使得其无法兼容不同类型的交易业务，更难以实现具有不同类型的交易业务的融合业务。现有的交易转接系统的通用性和兼容性都较差。
本申请提供一种基于多业务系统的交易转接方法、装置、设备、系统、存储介质及计算机程序产品，通过对多种交易业务的核心要素记性高度抽象，并增加能够体现不同交易业务的类型要素，构建一种能够兼容多种交易业务的多业务系统。可将任意一种交易业务提炼为“某用户在某商户购买某商品，从用户所持有的在机构开立的账户向商户支付一定数量、特定单位的某类别资源”的基本概念模型，以在交易发起方和交易承兑方之间完成交易。利用该多业务系统能够实现不同类型的资源的互联互通，支持不同类型账户、不同类型资源的组合交易，并能实现不同类型业务的权限的管理、维护和使用，该多业务系统可作为任意一种交易业务的交易转接系统，提高交易转接系统的通用性和兼容性。
为了便于理解，这里先对本申请实施例提供的多业务系统进行简单说明。图2为本申请实施例提供的多业务系统的一示例的示意图，如图2所示，作为交易发起方的商户/收单机构111、支付机构112、条码收单机构113以及其他收单机构114可通过各自的归一化标准接口接入统一接入端12，再通过统一接入端12接入多业务系统13，作为交易发起方的用户115可通过数字收银平台14接入多业务系统13，数字收银平台可为用于电子商务平台进行支付交易的平台。作为账户承兑方的发卡机构151、支付机构152、积分发行方153、票券发行方154和其他资源发行方155可通过各自的归一化标准接口接入统一接入端16，再通过统一接入端16接入多业务系统13。
下面对本申请提供的基于多业务系统的交易转接方法、装置、设备、存储介质及计算机程序产品分别进行说明。
本申请第一方面提供一种基于多业务系统的交易转接方法，该交易转接方法应用于多业务系统，即，该交易转接方法可由该多业务系统执行。图3为本申请一实施例提供的基于多业务系统的交易转接方法的流程图，如图3所示，该基于多业务系统的交易转接方法可包括步骤S201至步骤S203。
在步骤S201中，接收交易请求。
交易请求可由数字收银平台、商户/收单机构、支付机构、条码收单机构或其他收单机构发起，在此并不限定，但不管交易请求由哪一方发起，多业务系统接收到的交易请求的报文格式都是一致的。交易请求用于请求进行交易业务。交易请求可对应一次交易，但这一次交易可包括一个订单，也可包括多个订单，即，所述交易请求可对应一个支付订单或两个以上的支付订单，从而实现多订单的合并支付。一次交易用户可使用一种类型的账户，也可使用多种类型的账户组合交易。交易请求可包括至少一个交易子请求。交易子请求可根据用户进行交易的账户的账户类型的不同而划分，也可根据订单的不同划分，在此并不限定。
每个交易子请求可包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素。
付款方要素用于表征付款方的相关信息。在一些示例中，付款方要素可包括但不限于付款方标识、付款方个人信息和付款方补充信息。付款方标识用于标识付款方，如，付款方标识可包括付款方ID。付款方个人信息用于表征付款方的个人身份，如，付款方个人信息可包括付款方姓名。付款方补充信息可包括需要补充的付款方其他的信息，可根据具体场景、需求等设定，如，付款方补充信息可包括付款方的位置信息，位置信息可为全球定位系统(Global Positioning System，GPS)信息，但并不限于此。
收款方要素用于表征收款方的相关信息，在本申请实施例中，收款方可包括交易中的商户等。在一些示例中，收款方要素可包括但不限于收款方标识、收款方订单标识和收款方补充信息。收款方标识用于标识收款方，如，收款方标识可包括收款方ID。收款方订单标识包括本次交易与该收款方关联的订单标识，收款方订单标识具有唯一性。收款方补充信息可包括需要补充的收款方的其他信息，如，收款方补充信息可包括收款方的位置信息，位置信息可为GPS信息，但并不限于此。在一些示例中，交易请求中交易子请求可包括一组收款方要素或两组以上的收款方要素，一组收款方要素可表征一个收款方，不同组收款方要素表征不同的收款方，即，一次交易可对应两个以上的收款方，从而实现多订单支付中多收款方的收款。
账户承兑方要素用于表征交易资源的承兑方的信息。在一些示例中，账户承兑方要素可包括但不限于账户承兑方类型和账户承兑方标识。账户承兑方类型用于表征账户承兑方的类型，例如，账户承兑方类型可包括发卡行、支付机构、积分发行方、票券发行方等，在此并不限定。账户承兑方标识用于标识账户承兑方，如，账户承兑方标识可包括账户承兑方ID。账户要素可包括但不限于账户类型和账户标识。账户类型用于表征账户的类型，如，账户类型可包括卡账户、条码支付账户、积分账户、票券账户等。账户标识用于标识账户，如，账户标识可包括账户ID，账户ID与账户类型对应，账户ID可实现为卡号、条码账户ID、积分账户ID、票券码等。交易资源要素用于表征交易资源。例如，交易资源要素可包括但不限于交易资源量、交易资源单位、交易资源类型、交易标准资源类型和交易标准资源转化比率，在一些示例中，交易资源要素还可包括交易资源总量或交易标准资源总量。交易资源量为交易子请求对应的交易资源类型的交易资源的数量。交易资源单位也与交易资源类型对应，如，交易资源类型为人民币，则交易资源单位为元。交易标准资源类型表征作为标准的交易资源的类型，在交易结算时一般以交易标准资源类型的交易资源进行结算。交易标准资源转化比率为交易资源类型的交易资源变换为交易标准资源类型的交易资源的变换比率。
在一些示例中，交易子请求还可包括受理方要素和/或订单要素；受理方要素应用于三方架构的交易中，三方架构包括收款方、付款方和受理方，受理方要素用于表征受理方，受理方可为第三方支付机构等，在此并不限定；例如，受理方要素可包括受理方标识，受理方标识可包括受理方ID，受理方要素还可包括受理方类型；订单要素可用于表征订单的相关信息，例如，订单要素可包括订单内容等。
同一交易请求中不同的交易子请求中的账户承兑方要素、账户要素、交易资源要素中至少一者不同。在交易请求包括多个交易子请求的情况下，交易请求可能为多种类型的资源的组合交易的请求，即，多业务系统可支持通过支付卡、第三方支付账户、积分、票券等多种类型的资源的组合交易，对应地，交易请求中不同的交易子请求的账户承兑方要素、账户要素和交易资源要素可不同。例如，若交易请求包括三个交易子请求，第一个交易子请求用于利用支付卡进行支付，第二个交易子请求用于利用第三方支付账户进行支付，第三个交易子请求用于利用积分进行支付，则第一个交易子请求中的账户承兑方要素指示的账户承兑方为支付卡的发卡行，账户要素指示的账户为支付卡，交易资源要素指示的支付资源类型为金额，第二个交易子请求中的账户承兑方要素指示的账户承兑方为第三方支付机构，账户要素指示的账户为第三方支付账户，交易资源要素指示的支付资源类型为金额，第三个交易子请求中的账户承兑方要素指示的账户承兑方为积分发行方，账户要素指示的账户为积分账户，交易资源要素指示的支付资源类型为积分。交易子请求中交易资源要素中的交易资源类型和交易资源量可根据触发交易请求的用户的输入确定，即，用户可自行选择交易所采用的资源的类型和数量。
通过付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素的提取，将交易请求标准化，使得不同业务场景下，多业务系统自身就可根据相同标准格式的交易请求完成交易转接。
在一些示例中，交易请求可包括支付请求和退货请求。在交易请求为支付请求的情况下，实现的交易为支付交易。在交易请求为退货请求的情况下，实现的交易为退货交易。本申请实施例中的基于多业务系统的交易转接方法可支持一次交易中的部分退货或全部退货。
在步骤S202中，根据交易请求，确定承兑资源量，生成承兑请求。
承兑资源量为本次交易与账户承兑方要素对应的交易资源类型的资源的数量。在交易请求的交易资源要素中交易资源类型与账户承兑方要素中账户承兑方类型对应的情况下，可将交易请求的交易资源要素中的交易资源量确定为承兑资源量。在交易请求的交易资源要素中交易资源类型与账户承兑方要素中账户承兑方类型不对应的情况下，可将交易请求的交易资源要素中的交易资源量转换为账户承兑方要素中账户承兑方类型对应的交易资源的量，将转换得到的账户承兑方类型对应的交易资源的量确定为承兑资源量。承兑请求可包括付款方要素、收款方要素、账户要素和承兑资源量，具体内容可参见上述实施例中的相关说明，在此不再赘述。
在步骤S203中，向账户承兑方要素指示的账户承兑方发送承兑请求，以使账户承兑方根据承兑请求完成交易。
账户承兑方接收到承兑请求后，可确定付款方、收款方、交易涉及的账户以及交易需承兑的资源量，从而根据付款方、收款方、交易涉及的账户以及交易需承兑的资源量，完成承兑。账户承兑方完成承兑后，还可向多业务系统发送承兑应答，多业务系统根据承兑应答，可确定承兑成功或承兑失败，以便于进行后续的结算。
在一些示例中，交易子请求具有子交易标识和交易族标识，不同交易子请求的子交易标识不同，属于同一交易请求的交易子请求的交易族标识相同。子交易标识用于标识交易子请求指示的子交易，子交易标识对于交易子请求而言具有唯一性。交易族标识用于标识交易子请求所属的交易请求指示的交易，交易族标识相同的交易子请求属于同一次交易。在接收到每个交易子请求对应的承兑请求的承兑应答后，多业务系统可记录该交易子请求的子交易标识和交易族标识，以记录这一笔子交易。
通过付款方要素、收款方要素、账户要素和承兑资源量的提取，将承兑请求标准化，使得不同业务场景下，多业务系统自身就可根据相同标准格式的承兑请求完成交易转接。标准格式的交易请求和承兑请求使得多业务系统可接入各种类型的交易业务涉及到的交易方，并可实现各种类型的交易业务的转接。
在本申请实施例中，多业务系统可接收标准格式的交易请求，交易请求可包括至少一个交易子请求，交易子请求的格式统一标准化，交易子请求可包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素，多业务平台根据交易请求可确定本次交易需要与账户承兑方承兑的资源量，并生成包括付款方要素、所述收款方要素、所述账户要素和承兑资源量的承兑请求发送给账户承兑方，以使账户承兑方完成交易。通过付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素可将各种类型的交易业务的核心要素高度抽象出来，以及，通过付款方要素、所述收款方要素、所述账户要素和承兑资源量可将各种类型的交易业务需要账户承兑方得知的核心要素高度抽象出来，实现多业务系统与各种类型的交易业务的交易方都可通过标准的报文请求进行交互，实现各种类型的交易业务的业务表达，提高了交易转接的通用性和兼容性。
而且，通过标准化的交易请求中各要素的设置，能够实现积分、票券等非金额的资源的标准化流通，积分、票券等非金额类型的资源可基于交易资源要素转换为用于结算的金额类型的资源，以保障交易的兑付、结算。除了非金额类型的资源到金额类型的资源的转换，还可实现非金额类型的资源到其他非金额类型的资源的转换，以及，金额类型的资源到其他金额类型的资源的转换，实现异构资源的联网流通以及多种标准资源类型的资源的交易流通。此外，本申请实施例中基于多业务系统的交易转接方法还可实现异构资源的组合支付、多订单的合并支付、易购资源的分账清算，提高交易业务的系统处理的灵活性和扩展性。
在一些实施例中，进行异构资源的组合支付，对应地，交易请求包括多个交易子请求，每个交易子请求对应一种账户类型，一个承兑请求对应一个交易子请求。上述步骤S202可具体细化为：根据第一个所述交易子请求，确定第一个所述交易子请求的承兑资源量，生成与第一个所述交易子请求对应的所述承兑请求；在接收到第一个所述交易子请求对应的承兑应答且第一个所述交易子请求的交易标准资源量未达到所述交易请求指示的交易标准资源总量的情况下，根据第二个所述交易子请求，确定第二个所述交易子请求的承兑资源量，生成与第二个所述交易子请求对应的所述承兑请求，直至接收到第N个所述交易子请求对应的承兑应答且前N个所述交易子请求的交易标准资源量之和达到所述交易请求指示的交易标准资源总量为止，N为大于等于2的正整数。
在交易请求包括多个交易子请求的情况下，多业务系统可依次接收交易子请求，在处理完一个交易子请求后再处理下一个交易子请求。多业务系统接收第一个交易子请求，根据第一个交易子请求，确定第一个交易子请求的承兑资源量，生成第一个承兑请求，并向第一个交易子请求指示的账户承兑方发送该承兑请求。第一个交易子请求指示的账户承兑方根据该承兑请求进行承兑处理，向多业务系统反馈第一个承兑应答，该承兑应答表征承兑成功。多业务系统判断已经承兑的交易标准资源量是否达到了本次交易的交易标准资源总量，若未达到，则接收第二个交易子请求，根据第二个交易子请求，确定第二个交易子请求的承兑资源量，生成第二个承兑请求，并向第二个交易子请求指示的账户承兑方发送该承兑请求。以此类推，直至第N个交易子请求指示的账户承兑方反馈承兑应答，且已经承兑的交易标准资源量达到了本次交易的交易标准资源总量，则可不再接收本次交易请求中的其他交易子请求。
在一些示例中，交易请求为交易平台触发，交易平台可实现为电子商务平台，在此并不限定。多业务系统在接收到第N个所述交易子请求对应的承兑应答且前N个所述交易子请求的交易标准资源量之和达到所述交易请求指示的交易标准资源总量的情况下，向触发所述交易请求的交易平台发送交易通知，交易通知用于通知交易平台本次交易已成功。交易通知具有子交易标识和交易族标识，交易通知的交易族标识与交易请求的交易族标识相同。可将交易通知看做是交易请求指示的交易中的第N+1个子交易，但该第N+1个子交易主要用于通知交易平台，以使交易平台能够与多业务平台对齐信息，并不会产生新的资源扣除。N个子交易请求对应的子交易和交易通知对应的第N+1个子交易可通过交易族标识关联，多业务系统会记录这N+1个子交易的交易族标识和子交易标识，以便于后续通过交易族标识实现清算。
为了便于理解，这里以异构资源的组合支付为例对本申请实施例中基于多业务系统的交易转接方法进行说明。图4为本申请实施例提供的基于多业务系统的交易流程的一示例的示意图，在该示例中，用户通过交易平台下单后，选择支付卡、第三方支付账户和通信积分组合支付完成一笔200元的支付，如图4所示，该交易流程可包括步骤a1至步骤a24。
在步骤a1中，用户向交易平台发起支付订单。支付订单的总金额为200元。
在步骤a2中，交易平台调起数字收银平台。
在步骤a3中，用户向数字收银平台输入支付卡的支付金额。支付卡的支付金额为50元。
在步骤a4中，数字收银平台向多业务系统发送第一个交易子请求。在第一个交易子请求中，账户承兑方要素指示的账户承兑方为支付卡的发卡行，账户要素指示的账户为支付卡，交易资源要素指示的交易标准资源总量即总金额为200元，交易资源要素指示的该子交易的交易资源量为50元，交易资源要素指示的交易资源类型和交易标准资源类型为人民币，交易资源要素指示的交易标准资源转化比率为1:1。
在步骤a5中，多业务系统根据第一个交易子请求，向支付卡的发卡行发送第一个承兑请求。承兑请求中的承兑资源量为50元。
在步骤a6中，多业务系统接收支付卡的发卡行发送的承兑应答。承兑应答表征承兑成功。
在步骤a7中，多业务系统记录第一笔子交易的子交易标识TransId1和交易族标识TransFamilyId。
在步骤a8中，多业务系统向数字收银平台发送交易应答。交易应答指示本次交易的待支付金额为150元。
在步骤a9中，用户向数字收银平台输入第三方支付账户的支付金额。第三方支付账户的支付金额为90元。
在步骤a10中，数字收银平台向多业务系统发送第二个交易子请求。在第二个交易子请求中，账户承兑方要素指示的账户承兑方为第三方支付机构，账户要素指示的账户为第三方支付账户，交易资源要素指示的交易标准资源总量即总金额为200元，交易资源要素指示的该子交易的交易资源量为90元，交易资源要素指示的交易资源类型和交易标准资源类型为人民币，交易资源要素指示的交易标准资源转化比率为1:1。
在步骤a11中，多业务系统根据第二个交易子请求，向支付卡的发卡行发送第二个承兑请求。承兑请求中的承兑资源量为90元。
在步骤a12中，多业务系统接收支付卡的发卡行发送的承兑应答。承兑应答表征承兑成功。
在步骤a13中，多业务系统记录第二笔子交易的子交易标识TransId2和交易族标识TransFamilyId。
在步骤a14中，多业务系统向数字收银平台发送交易应答。交易应答指示本次交易的待支付金额为60元。
在步骤a15中，用户向数字收银平台输入积分的支付积分量。支付积分量为6000，积分与金额的转化比率为100:1，6000积分对应的支付金额为60元。
在步骤a16中，数字收银平台向多业务系统发送第三个交易子请求。在第三个交易子请求中，账户承兑方要素指示的账户承兑方为通信积分发行方，账户要素指示的账户为积分账户，交易资源要素指示的交易标准资源总量即总金额为200元，交易资源要素指示的该子交易的交易资源量为6000积分，交易资源要素指示的交易资源类型和交易标准资源类型为人民币，交易资源要素指示的交易标准资源转化比率为100:1。
在步骤a17中，多业务系统根据第三个交易子请求，向支付卡的发卡行发送第一个承兑请求。承兑请求中的承兑资源量为6000积分。
在步骤a18中，多业务系统接收通信积分发行方发送的承兑应答。承兑应答表征承兑成功。
在步骤a19中，多业务系统记录第三笔子交易的子交易标识TransId3和交易族标识TransFamilyId。
在步骤a20中，多业务系统向数字收银平台发送交易应答。多业务系统根据积分与金额的转化比率，将积分转换为金额，得到第三笔子交易的支付金额为60元，计算得到本次交易的待支付金额为0元，交易应答指示本次交易的待支付金额为0元。
在步骤a21中，多业务系统向交易平台发送交易通知。交易通知表征本次交易的待支付金额为0元，已经付款200元。
在步骤a22中，多业务系统记录第四笔子交易的子交易标识TransId4和交易族标识TransFamilyId。需要说明的是，这里是将对交易平台的通知视为第四笔子交易，但第四笔子交易只是通知作用，是为了交易平台便于结算，并未产生新的支付金额。
在步骤a23中，交易平台向多业务系统反馈交易通知应答。
在步骤a24中，多业务系统向数字收银平台发送交易完成通知。交易完成通知表征本次交易完成。
上述步骤a1至步骤a24的其他具体内容可参见上述实施例中的相关说明，在此不再赘述。
在交易子请求中的交易资源类型与交易标准资源类型不同的情况下，为了便于结算，需要将交易资源类型对应的交易资源量转换为交易标准资源类型对应的交易标准资源量，尤其是对于积分等非金额的资源，积分等非金额的资源的账户承兑方可预先开设标准资源账户，以便于将标准资源账户中交易标准资源量的资源转入收款方的账户。交易资源要素包括交易资源量、交易资源类型、交易标准资源类型和交易标准资源转化比率。在交易子请求中的交易资源类型与交易标准资源类型不同的情况下，多业务系统按照交易标准资源转化比率，将交易子请求中的交易资源量转换为与交易标准资源类型对应的交易标准资源量；利用将交易子请求中账户承兑方要素指示的账户承兑方预先设置的标准资源账户，根据转换得到的交易标准资源量，完成交易。
在一些跨境交易的场景中，需要进行两种交易标准资源的转换，两种交易标准资源中一种为境外的交易标准资源，另一种为境内的交易标准资源。在两种交易标准资源的转换中，一种交易标准资源作为中间转换的交易标准资源，另一种作为最终转换的交易标准资源。跨境交易的账户承兑方可预先与多业务系统签订预转换合约，多业务系统预存该预转换合约，预转换合约可包括预交易标准资源类型和预交易标准资源转化比率，预交易标准资源类型为中间转换的交易标准资源类型，预交易标准资源转换比率为中间转换的交易标准资源转换比率。交易子请求中的交易资源要素包括交易资源量、交易资源类型、交易标准资源类型和交易标准资源转化比率。上述步骤S202可具体细化为：在交易子请求中交易资源类型与交易标准资源类型不同且交易子请求中账户承兑方要素指示的账户承兑方具有预转换合约的情况下，多业务系统按照预交易标准资源转化比率，将交易请求中的交易资源量转换为与预交易标准资源类型对应的预交易标准资源量；将预交易标准资源量转换为与交易子请求中交易标准资源类型对应的交易标准资源量，并将转换得到的交易标准资源量确定为承兑资源量。
例如，若某用户期望利用国家A1的银行积分完成在国家A2的电子商务平台的支付，则国家A1的银行可预先与多业务平台签订预转换合约，预转换合约中的预交易标准资源类型为国家A1的交易标准资源类型，预转换合约中的预交易标准资源转化比率为国家A1的银行积分转换为国家A1中的交易标准资源类型的交易资源的转换比率。多业务系统可按照预交易标准资源，将国家A1的银行积分转换为国家A1的交易标准资源类型的交易标准资源量，再将国家A1的交易标准资源类型的交易标准资源量转换为国家A2的交易标准资源类型的交易标准资源量，并将国家A2的交易标准资源类型的交易标准资源量确定为承兑资源量，以生成承兑请求。
在一些实施例中，多业务系统还可实现两种交易资源类型的交易资源通过另一种交易资源类型的交易资源进行的转换。交易资源要素可包括第一交易标准资源类型、第一交易标准资源转化比率、第二交易标准资源类型和第二交易标准资源转化比率。第一交易标准资源类型与第一交易标准资源转化比率对应，第二交易标准资源类型与第二交易标准资源转化比率对应。上述步骤S202可具体细化为：按照第一交易标准资源转化比率，将交易子请求中的交易资源量转换为与第一交易标准资源类型对应的第一交易标准资源量；按照第二交易标准资源转化比率，将第一交易标准资源量转换为与第二交易标准资源类型对应的第二交易标准资源量，并将第二交易标准资源量确定为承兑资源量，生成承兑请求。
为了便于理解，下面以积分和航空里程通过人民币金额进行转换为例对本申请实施例中基于多业务系统的交易转接方法进行说明。图5为本申请实施例提供的基于多业务系统的交易流程的另一示例的示意图，在该示例中，用户通过第三方支付机构请求将银行积分转换为航空公司的里程，如图5所示，该交易流程可包括步骤b1至步骤b9。
在步骤b1中，用户向第三方支付机构发起兑换。第三方支付机构在本示例中为受理方。
在步骤b2中，第三方支付机构向多业务系统发送交易请求。该交易请求用于请求将100银行积分兑换为航空公司的里程。
在步骤b3中，多业务系统向积分发行银行发送转出承兑请求。转出承兑请求用于请求将100银行积分转出用户的银行积分账户。银行在本示例中为付款方。
在步骤b4中，积分发行银行向多业务系统反馈转出承兑应答。转出承兑应答表征银行积分转出成功。
在步骤b5中，多业务系统进行交易资源的转换。具体地，第一交易标准资源类型为人民币，第一交易标准资源转化比率为100:1，即，100银行积分可转换为1元人民币，第二易标准资源类型为里程，第二交易标准资源转化比率为1:500，即，1元人民币可转换为500里程。
在步骤b6中，多业务系统向航空公司发送转入承兑请求。转入承兑应答用于请求将转换得到的500里程转入用户在航空公司的账户。航空公司在本示例中为收款方。
在步骤b7中，航空公司向多业务系统反馈转入承兑应答。转入承兑应答表征里程转入成功。
在步骤b8中，多业务系统向第三方支付机构发送交易应答。交易应答表征交易成功。
在步骤b9中，第三方支付结构向用户展示交易成功的交易结果。
上述步骤b1至步骤b9的其他具体内容可参见上述实施例中的相关说明，在此不再赘述。
在一些实施例中，在接收到交易请求后，可对本次交易先进行校验，校验通过后，再进行后续的交易流程。可通过灵活化的校验插件来实现各类校验功能，从资源的流通能力、账户承兑方的流通能力、付款方的流通能力以及收款方的流通能力等多方面记性综合管理，以保证交易安全。校验插件采用统一标准的输入参数和输出参数，校验插件的调用也统一标准化，在多业务系统有功能更新的情况下，可通过新增插件的方式实现更新的功能，新增的插件并不会影响原有的业务功能逻辑，通过插件插拔的方式可实现交易业务的灵活拓展。
图6为本申请另一实施例提供的基于多业务系统的交易转接方法的流程图，图6与图3的不同之处在于，图6所示的基于多业务系统的交易转接方法还可包括步骤S204，图3中的步骤S202可具体细化为图6所示的步骤S2021。
在步骤S204中，根据交易请求，调用与账户要素对应的校验插件，对交易请求指示的交易进行校验。
交易请求中交易子请求包括的账户要素不同，调用的校验插件也不同。可根据交易请求中交易子请求包括的账户要素，确定需要调用的校验插件，并调用该校验插件，由校验插件执行对交易请求指示的交易的校验。
在一些示例中，校验插件可用于对交易资源要素、账户承兑方要素、付款方要素、收款方要素中的一者或两者以上进行校验。校验插件包括权限校验插件、额度校验插件、风险控制检验插件中的一种或两种以上。权限校验插件可进一步包括交易资源权限校验插件、账户承兑方权限校验插件、付款方权限校验插件、收款方权限校验插件等。额度校验插件可进一步包括交易资源额度校验插件、账户承兑方额度校验插件、付款方额度校验插件、收款方额度校验插件等。风险控制检验插件可进一步包括交易资源风险控制校验插件、账户承兑方风险控制校验插件、付款方风险控制校验插件、收款方风险控制校验插件等。
例如，图7为本申请实施例提供的校验流程的一示例的示意图，如图7所示，可依次进行权限校验、额度校验和风险控制校验，还可进行其他校验。权限校验可包括对交易资源流通的权限校验、对账户承兑方流通的权限校验、对付款方流通的权限校验和对收款方流通的权限校验。对交易资源流通的权限校验可按照预先设定的交易资源开关、交易资源白名单、交易资源黑名单等进行交易资源的准入权限校验，即校验该交易资源是否允许在交易业务中流通。对账户承兑方流通的权限校验可按照预先设定的分级规则来对账户承兑方的权限进行校验，分级规则可根据账户承兑方、账户承兑方的承兑额度、账户承兑方白名单、账户承兑方可参与的交易的白名单等设置。对付款方流通的权限校验可按照预先设定的白名单、黄名单、黑名单等进行校验。对收款方流通的权限校验可按照预先设定的白名单、黄名单、黑名单等进行校验。同理，额度校验可包括对交易资源流通的额度校验、对账户承兑方流通的额度校验、对付款方流通的额度校验和对收款方流通的额度校验。额度校验与上述权限校验的方式类似，只不过是以额度为主体进行校验，可按照预先设定的额度规则来对交易资源、账户承兑方、付款方和收款方进行额度的验证。风险控制校验可包括对交易资源流通的风险控制校验、对账户承兑方流通的风险校验、对付款方流通的风险校验和对收款方流通的风险校验。风险控制校验与上述权限校验的方式类似，只不过是以风险控制为主体进行校验，可按照预先设定的风险规则、风险白名单、风险黄名单、风险黑名单等来对交易资源、账户承兑方、付款方和收款方进行风险控制的校验。
通过对交易资源、账户承兑方、付款方、收款方的校验，提高交易安全性。且校验插件中设置的校验规则即可实现校验的灵活配置，有可实现高效校验。
上述实施例中校验插件的输入数据和输出数据都是统一标准化的，校验插件可根据标准化的输入数据进行处理，从而得到检验结果。具体地，多业务系统可从交易请求中获取校验插件要求的标准输入数据；调用校验插件，将标准输入数据输入校验插件，以使校验插件基于标准输入数据输出校验结果标准数据；从校验插件获取校验结果标准数据。标准输入数据可包括付款方账户标识、交易资源量、交易资源类型、收款方标识和校验类型，校验类型与账户要素指示的账户类型对应，在一些示例中，校验类型可直接用账户类型赋值。校验结果标准数据包括校验结果。
例如，图8为本申请实施例提供的风险控制校验调用校验插件的一示例的示意图，如图8所示，风险控制校验可调用的校验插件可包括支付卡风险校验插件、积分风险校验插件以及其他校验插件。各校验插件可预先在插件注册中心进行注册，多业务系统可预先从插件注册中心订阅需要调用的校验插件，在需要调用的时候，调用对应的插件。例如，若账户要素指示的账户为支付卡，则调用支付卡风险校验插件；若账户要素指示的账户为积分账户，则调用积分风险校验插件。校验插件的标准输入数据可包括付款方账户标识PayerAcctId、交易资源量TrxTmt、交易资源类型currency、收款方标识merchantNO和校验类型serviceGroup。检验插件的校验结果标准数据可包括风险得分score。
在步骤S2021中，在校验通过的情况下，根据交易请求，确定承兑资源量，生成承兑请求。
若校验未通过，则中止本次交易。
需要说明的是，本申请实施例中多业务系统中除校验以外的功能也可通过插件实现，例如，交易资源的转换、清算等功能都可实现为插件。本申请实施例可支持各个接入方在接入、权限、额度、风险控制、运营管理等层面上的插件化，各插件可动态的加载和卸载，新增的功能逻辑通过插件实现不会影响原有的业务功能逻辑，使得交易业务的实现更加灵活。
在一些实施例中，需要给多业务系统的接入方留出改造接入的时间，在多业务系统的接入方还未改造成功时，可为多业务系统的接入方设置系统过渡阶段，并为多业务系统配置前置兼容系统和后置兼容系统，通过前置兼容系统和后置兼容系统兼容原始接口的报文协议、接口类型等。前置兼容系统用于进行将接入方的原始接口发送来的请求转换为符合多业务系统要求的交易请求，后置兼容系统可用于将多业务系统输出的承兑请求转换为符合接入方的原始接口的请求。接入方可包括交易发起方和账户承兑方，交易发起方可包括用户、第三方支付机构、交易平台、数字收银平台、收单机构等。
在系统过渡阶段，通过前置兼容系统将使用原始接口的交易发起方发送的请求转换为交易请求；在系统过渡阶段，通过后置兼容系统将承兑请求转换为符合账户承兑方的原始接口要求的请求，并向账户承兑方发送。例如，图9为本申请实施例提供的多业务系统的另一示例的示意图，图9与图2的不同之处在于，图9所示的多业务系统13还配置有前置兼容系统17和后置兼容系统18，商户/收单机构111、支付机构112、条码收单机构113以及其他收单机构114可通过归一化标准接口接入统一接入端12，商户/收单机构111、支付机构112、条码收单机构113以及其他收单机构114也可通过原始接口接入前置兼容系统17，发卡机构151、支付机构152、积分发行方153、票券发行方154和其他资源发行方155可通过归一化标准接口接入统一接入端16，发卡机构151、支付机构152、积分发行方153、票券发行方154和其他资源发行方155可通过原始接口接入后置兼容系统18。
本申请第二方面提供一种基于多业务系统的交易转接装置，应用于多业务系统。图10为本申请一实施例提供的基于多业务系统的交易转接装置的结构示意图，如图10所示，该基于多业务系统的交易转接装置300可包括接收模块301、信息处理模块302和发送模块303。
接收模块301可用于接收交易请求。
交易请求包括至少一个交易子请求。每个交易子请求包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素。同一交易请求中不同的交易子请求中的账户承兑方要素、账户要素、交易资源要素中至少一者不同。
信息处理模块302可用于根据交易请求，确定承兑资源量，生成承兑请求。
承兑请求包括付款方要素、收款方要素、账户要素和承兑资源量。
发送模块303可用于向账户承兑方要素指示的账户承兑方发送承兑请求，以使账户承兑方根据承兑请求完成交易。
在一些实施例中，交易请求包括多个交易子请求，每个交易子请求对应一种账户类型。信息处理模块302可具体用于：根据第一个交易子请求，确定第一个交易子请求的承兑资源量，生成与第一个交易子请求对应的承兑请求；在接收到第一个交易子请求对应的承兑应答且第一个交易子请求的交易标准资源量未达到交易请求指示的交易标准资源总量的情况下，根据第二个交易子请求，确定第二个交易子请求的承兑资源量，生成与第二个交易子请求对应的承兑请求，直至接收到第N个交易子请求对应的承兑应答且前N个交易子请求的交易标准资源量之和达到交易请求指示的交易标准资源总量为止，N为大于等于2的正整数。
在一些实施例中，信息处理模块302还可用于：在接收到第N个交易子请求对应的承兑应答且前N个交易子请求的交易标准资源量之和达到交易请求指示的交易标准资源总量的情况下，向触发交易请求的交易平台发送交易通知。
其中，交易通知具有子交易标识和交易族标识，交易通知的交易族标识与交易请求的交易族标识相同。
在一些实施例中，交易资源要素包括交易资源量、交易资源类型、交易标准资源类型和交易标准资源转化比率。信息处理模块302还可用于：在交易子请求中的交易资源类型与交易标准资源类型不同的情况下，按照交易标准资源转化比率，将交易子请求中的交易资源量转换为与交易标准资源类型对应的交易标准资源量；利用将交易子请求中账户承兑方要素指示的账户承兑方预先设置的标准资源账户，根据转换得到的交易标准资源量，完成交易。
在一些实施例中，交易子请求具有子交易标识和交易族标识，不同交易子请求的子交易标识不同，属于同一交易请求的交易子请求的交易族标识相同。
在一些实施例中，交易资源要素包括交易资源量、交易资源类型、交易标准资源类型和交易标准资源转化比率，多业务系统预存有预转换合约，预转换合约包括预交易标准资源类型和预交易标准资源转化比率。
信息处理模块302可具体用于：在交易子请求中交易资源类型与交易标准资源类型不同且交易子请求中账户承兑方要素指示的账户承兑方具有预转换合约的情况下，按照预交易标准资源转化比率，将交易请求中的交易资源量转换为与预交易标准资源类型对应的预交易标准资源量；将预交易标准资源量转换为与交易子请求中交易标准资源类型对应的交易标准资源量，并将转换得到的交易标准资源量确定为承兑资源量。
在一些实施例中，交易资源要素包括第一交易标准资源类型、第一交易标准资源转化比率、第二交易标准资源类型和第二交易标准资源转化比率。信息处理模块302可具体用于：按照第一交易标准资源转化比率，将交易子请求中的交易资源量转换为与第一交易标准资源类型对应的第一交易标准资源量；按照第二交易标准资源转化比率，将第一交易标准资源量转换为与第二交易标准资源类型对应的第二交易标准资源量，并将第二交易标准资源量确定为承兑资源量。
在一些实施例中，基于多业务系统的交易转接装置300还可包括校验模块。校验模块可用于：根据交易请求，调用与账户要素对应的校验插件，对交易请求指示的交易进行校验。
信息处理模块302可具体用于：在校验通过的情况下，根据交易请求，确定承兑资源量，生成承兑请求。
在一些示例中，校验插件用于对交易资源要素、账户承兑方要素、付款方要素、收款方要素中的一者或两者以上进行校验。校验插件包括权限校验插件、额度校验插件、风险控制检验插件中的一种或两种以上。
在一些示例中，校验模块可具体用于：从交易请求中获取校验插件要求的标准输入数据；调用校验插件，将标准输入数据输入校验插件，以使校验插件基于标准输入数据输出校验结果标准数据；从校验插件获取校验结果标准数据。
在一些示例中，交易请求包括支付请求和退货请求。
在一些实施例中，多业务系统配置有前置兼容系统和后置兼容系统。多业务系统的交易转接装置300还包括转换模块，转换模块可用于：在系统过渡阶段，通过前置兼容系统将使用原始接口的交易发起方发送的请求转换为交易请求；在系统过渡阶段，通过后置兼容系统将承兑请求转换为符合账户承兑方的原始接口要求的请求，并向账户承兑方发送。
在一些示例中，交易请求对应一个支付订单或两个以上的支付订单。交易请求中交易子请求包括一组收款方要素或两组以上的收款方要素。
在一些示例中，付款方要素包括付款方标识、付款方个人信息和付款方补充信息。
收款方要素包括收款方标识、收款方订单标识和收款方补充信息。
账户要素包括账户类型和账户标识。
账户承兑方要素包括账户承兑方类型和账户承兑方标识。
交易资源要素包括交易资源量、交易资源单位、交易资源类型、交易标准资源类型和交易标准资源转化比率。
在一些示例中，交易子请求还包括受理方要素和/或订单要素。
需要说明的是，该基于多业务系统的交易转接装置300是与上述基于多业务系统的交易转接方法对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。
本申请第三方面还提供了一种基于多业务系统的交易转接设备。图11为本申请一实施例提供的基于多业务系统的交易转接设备的结构示意图。如图11所示，基于多业务系统的交易转接设备400包括存储器401、处理器402及存储在存储器401上并可在处理器402上运行的计算机程序。
在一些示例中，上述处理器402可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。
存储器401可包括只读存储器(Read-Only Memory，ROM)，随机存取存储器(Random Access Memory，RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请实施例中基于多业务系统的交易转接方法所描述的操作。
处理器402通过读取存储器401中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述实施例中的基于多业务系统的交易转接方法。
在一些示例中，基于多业务系统的交易转接设备400还可包括通信接口403和总线404。其中，如图11所示，存储器401、处理器402、通信接口403通过总线404连接并完成相互间的通信。
通信接口403，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口403接入输入设备和/或输出设备。
总线404包括硬件、软件或两者，将基于多业务系统的交易转接设备400的部件彼此耦接在一起。举例来说而非限制，总线404可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Enhanced Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industry Standard Architecture，ISA)总线、无限带宽互连、低引脚数(Low pin count，LPC)总线、存储器总线、微信道架构(Micro Channel Architecture，MCA)总线、外围组件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-E)总线、串行高级技术附件(Serial Advanced Technology Attachment，SATA)总线、视频电子标准协会局部(Video Electronics Standards Association Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线404可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。
本申请第四方面提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，该计算机程序指令被处理器执行时可实现上述实施例中的基于多业务系统的交易转接方法，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，上述计算机可读存储介质可包括非暂态计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等，在此并不限定。
本申请第五方面提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于多业务系统的交易转接方法，且能达到相同的技术效果，为避免重复，这里不再赘述。
需要明确的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。对于装置实施例、设备实施例、计算机可读存储介质实施例、计算机程序产品实施例而言，相关之处可以参见方法实施例的说明部分。本申请并不局限于上文所描述并在图中示出的特定步骤和结构。本领域的技术人员可以在领会本申请的精神之后，作出各种改变、修改和添加，或者改变步骤之间的顺序。并且，为了简明起见，这里省略对已知方法技术的详细描述。
上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。
本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；数量词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。

Claims (19)

  1. 一种基于多业务系统的交易转接方法，应用于多业务系统，所述方法包括：
    接收交易请求，所述交易请求包括至少一个交易子请求，每个所述交易子请求包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素，同一所述交易请求中不同的所述交易子请求中的所述账户承兑方要素、所述账户要素、所述交易资源要素中至少一者不同；
    根据所述交易请求，确定承兑资源量，生成承兑请求，所述承兑请求包括所述付款方要素、所述收款方要素、所述账户要素和承兑资源量；
    向所述账户承兑方要素指示的账户承兑方发送所述承兑请求，以使账户承兑方根据所述承兑请求完成交易。
  2. 根据权利要求1所述的方法，其中，所述交易请求包括多个所述交易子请求，每个交易子请求对应一种账户类型；
    所述根据所述交易请求，确定承兑资源量，生成承兑请求，包括：
    根据第一个所述交易子请求，确定第一个所述交易子请求的承兑资源量，生成与第一个所述交易子请求对应的所述承兑请求；
    在接收到第一个所述交易子请求对应的承兑应答且第一个所述交易子请求的交易标准资源量未达到所述交易请求指示的交易标准资源总量的情况下，根据第二个所述交易子请求，确定第二个所述交易子请求的承兑资源量，生成与第二个所述交易子请求对应的所述承兑请求，直至接收到第N个所述交易子请求对应的承兑应答且前N个所述交易子请求的交易标准资源量之和达到所述交易请求指示的交易标准资源总量为止，N为大于等于2的正整数。
  3. 根据权利要求2所述的方法，还包括：
    在接收到第N个所述交易子请求对应的承兑应答且前N个所述交易子请求的交易标准资源量之和达到所述交易请求指示的交易标准资源总量的情况下，向触发所述交易请求的交易平台发送交易通知；
    其中，所述交易通知具有子交易标识和交易族标识，所述交易通知的交易族标识与所述交易请求的交易族标识相同。
  4. 根据权利要求1所述的方法，其中，所述交易资源要素包括交易资源量、交易资源类型、交易标准资源类型和交易标准资源转化比率；
    所述方法还包括，包括：
    在所述交易子请求中的交易资源类型与交易标准资源类型不同的情况下，按照交易标准资源转化比率，将所述交易子请求中的交易资源量转换为与交易标准资源类型对应的交易标准资源量；
    利用将所述交易子请求中所述账户承兑方要素指示的账户承兑方预先设置的标准资源账户，根据转换得到的交易标准资源量，完成交易。
  5. 根据权利要求1所述的方法，其中，所述交易子请求具有子交易标识和交易族标识，不同所述交易子请求的子交易标识不同，属于同一所述交易请求的所述交易子请求的交易族标识相同。
  6. 根据权利要求1所述的方法，其中，所述交易资源要素包括交易资源量、交易资源类型、交易标准资源类型和交易标准资源转化比率，所述多业务系统预存有预转换合约，所述预转换合约包括预交易标准资源类型和预交易标准资源转化比率；
    所述根据所述交易请求，确定承兑资源量，包括：
    在所述交易子请求中交易资源类型与交易标准资源类型不同且所述交易子请求中所述账户承兑方要素指示的账户承兑方具有所述预转换合约的情况下，按照所述预交易标准资源转化比率，将所述交易请求中的交易资源量转换为与预交易标准资源类型对应的预交易标准资源量；
    将预交易标准资源量转换为与所述交易子请求中交易标准资源类型对应的交易标准资源量，并将转换得到的交易标准资源量确定为承兑资源量。
  7. 根据权利要求1所述的方法，其中，所述交易资源要素包括第一交易标准资源类型、第一交易标准资源转化比率、第二交易标准资源类型和第二交易标准资源转化比率；
    所述根据所述交易请求，确定承兑资源量，包括：
    按照第一交易标准资源转化比率，将所述交易子请求中的交易资源量转换为与所述第一交易标准资源类型对应的第一交易标准资源量；
    按照第二交易标准资源转化比率，将所述第一交易标准资源量转换为与所述第二交易标准资源类型对应的第二交易标准资源量，并将所述第二交易标准资源量确定为所述承兑资源量。
  8. 根据权利要求1所述的方法，在所述根据所述交易请求，确定承兑资源量，生成承兑请求之前，还包括：
    根据所述交易请求，调用与所述账户要素对应的校验插件，对所述交易请求指示的交易进行校验；
    所述根据所述交易请求，确定承兑资源量，生成承兑请求，包括：
    在校验通过的情况下，根据所述交易请求，确定承兑资源量，生成所述承兑请求。
  9. 根据权利要求8所述的方法，其中，
    所述校验插件用于对所述交易资源要素、所述账户承兑方要素、所述付款方要素、所述收款方要素中的一者或两者以上进行校验；
    所述校验插件包括权限校验插件、额度校验插件、风险控制检验插件中的一种或两种以上。
  10. 根据权利要求8所述的方法，其中，所述根据所述交易请求，调用与所述账户要素对应的校验插件，对所述交易请求指示的交易进行校验，包括：
    从所述交易请求中获取所述校验插件要求的标准输入数据；
    调用所述校验插件，将所述标准输入数据输入所述校验插件，以使所述校验插件基于所述标准输入数据输出校验结果标准数据；
    从所述校验插件获取所述校验结果标准数据。
  11. 根据权利要求1所述的方法，其中，所述交易请求包括支付请求和退货请求。
  12. 根据权利要求1所述的方法，其中，所述多业务系统配置有前置兼容系统和后置兼容系统；
    所述方法还包括：
    在系统过渡阶段，通过所述前置兼容系统将使用原始接口的交易发起方发送的请求转换为所述交易请求；
    在系统过渡阶段，通过所述后置兼容系统将承兑请求转换为符合账户承兑方的原始接口要求的请求，并向账户承兑方发送。
  13. 根据权利要求1所述的方法，其中，
    所述交易请求对应一个支付订单或两个以上的支付订单；
    所述交易请求中所述交易子请求包括一组所述收款方要素或两组以上的所述收款方要素。
  14. 根据权利要求1至13中任意一项所述的方法，其中，
    所述付款方要素包括付款方标识、付款方个人信息和付款方补充信息；
    所述收款方要素包括收款方标识、收款方订单标识和收款方补充信息；
    所述账户要素包括账户类型和账户标识；
    所述账户承兑方要素包括账户承兑方类型和账户承兑方标识；
    所述交易资源要素包括交易资源量、交易资源单位、交易资源类型、交易标准资源类型和交易标准资源转化比率。
  15. 根据权利要求1至13中任意一项所述的方法，其中，所述交易子请求还包括受理方要素和/或订单要素。
  16. 一种基于多业务系统的交易转接装置，应用于多业务系统，所述装置包括：
    接收模块，用于接收交易请求，所述交易请求包括至少一个交易子请求，每个所述交易子请求包括付款方要素、收款方要素、账户承兑方要素、账户要素和交易资源要素，同一所述交易请求中不同的所述交易子请求中的所述账户承兑方要素、所述账户要素、所述交易资源要素中至少一者不同；
    信息处理模块，用于根据所述交易请求，确定承兑资源量，生成承兑请求，所述承兑请求包括所述付款方要素、所述收款方要素、所述账户要素和承兑资源量；
    发送模块，用于向所述账户承兑方要素指示的账户承兑方发送所述承兑请求，以使账户承兑方根据所述承兑请求完成交易。
  17. 一种基于多业务系统的交易转接设备，包括：处理器以及存储有计算机程序指令的存储器；
    所述处理器执行所述计算机程序指令时实现如权利要求1至15中任意一项所述的基于多业务系统的交易转接方法。
  18. 一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1至15中任意一项所述的基于多业务系统的交易转接方法。
  19. 一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现权利要求1至15中任意一项所述的基于多业务系统的交易转接方法。
PCT/CN2024/141374 2024-07-15 2024-12-23 基于多业务系统的交易转接方法、装置、设备及介质 Pending WO2026016409A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410947068.4 2024-07-15
CN202410947068.4A CN118941283A (zh) 2024-07-15 2024-07-15 基于多业务系统的交易转接方法、装置、设备及介质

Publications (1)

Publication Number Publication Date
WO2026016409A1 true WO2026016409A1 (zh) 2026-01-22

Family

ID=93343638

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/141374 Pending WO2026016409A1 (zh) 2024-07-15 2024-12-23 基于多业务系统的交易转接方法、装置、设备及介质

Country Status (3)

Country Link
CN (1) CN118941283A (zh)
TW (1) TWI909909B (zh)
WO (1) WO2026016409A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118941283A (zh) * 2024-07-15 2024-11-12 中国银联股份有限公司 基于多业务系统的交易转接方法、装置、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102855557A (zh) * 2011-06-27 2013-01-02 乐活在线（北京）网络技术有限公司 网络交易支付处理系统及方法
US20160132876A1 (en) * 2014-02-11 2016-05-12 Google Inc. Automatic closed loop payment redemption
CN106097086A (zh) * 2016-06-07 2016-11-09 中国建设银行股份有限公司 用于企业转账的数据处理方法、装置和系统
CN116245530A (zh) * 2022-12-26 2023-06-09 中国民生银行股份有限公司 一种多类型支付交易方法、装置、电子设备以及存储介质
CN118941283A (zh) * 2024-07-15 2024-11-12 中国银联股份有限公司 基于多业务系统的交易转接方法、装置、设备及介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8527408B2 (en) * 2002-05-06 2013-09-03 Bottom Line Technologies (De), Inc. Integrated payment system
KR101053295B1 (ko) * 2010-11-08 2011-08-01 나갑준 지불처리 시스템 및 방법
CN111260360A (zh) * 2020-01-13 2020-06-09 支付宝实验室(新加坡)有限公司 基于条码支付的实现方法和装置
CN114429340B (zh) * 2020-10-29 2026-02-10 腾讯科技（深圳）有限公司 电子支付的处理方法、装置、电子设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102855557A (zh) * 2011-06-27 2013-01-02 乐活在线（北京）网络技术有限公司 网络交易支付处理系统及方法
US20160132876A1 (en) * 2014-02-11 2016-05-12 Google Inc. Automatic closed loop payment redemption
CN106097086A (zh) * 2016-06-07 2016-11-09 中国建设银行股份有限公司 用于企业转账的数据处理方法、装置和系统
CN116245530A (zh) * 2022-12-26 2023-06-09 中国民生银行股份有限公司 一种多类型支付交易方法、装置、电子设备以及存储介质
CN118941283A (zh) * 2024-07-15 2024-11-12 中国银联股份有限公司 基于多业务系统的交易转接方法、装置、设备及介质

Also Published As

Publication number Publication date
CN118941283A (zh) 2024-11-12
TWI909909B (zh) 2025-12-21

Similar Documents

Publication Publication Date Title
CN113205331B (zh) 一种支付方法及装置、电子设备和存储介质
CN112669042A (zh) 支付方法、服务器、用户终端、系统及存储介质
US20140310166A1 (en) System and method for loading stored value accounts
CN111695970A (zh) 一种订单处理方法和系统
US10489787B2 (en) Multi-leg transaction processing
TWI909909B (zh) 基於多業務系統的交易轉接方法、裝置、設備及介質
TW202605700A (zh) 基於多業務系統的交易轉接方法、裝置、設備及介質
WO2022262527A1 (zh) 一种基于数字货币的支付方法、平台、终端及支付系统
CN103366270A (zh) 一种多平台的数据交互方法及系统
CN117078248A (zh) 电子交易方法、装置、设备、系统及介质
CN114462991B (zh) 基于数字货币的条件交易的方法和装置
CN110874728A (zh) 网上支付系统、网上支付方法、装置、介质及服务器
WO2014032206A1 (zh) 一种快速支付系统和相应方法
KR20090001844A (ko) 모바일뱅킹을 이용한 모바일간 결제 서비스 방법
HK40115594A (zh) 基於多业务系统的交易转接方法、装置、设备及介质
WO2014146286A1 (zh) 利用实时通讯的银行卡安全支付系统和方法
CN112163858A (zh) 一种交易方法、装置及设备
US20260004282A1 (en) Token services for non-fungible tokens
EP4736101A1 (en) Card on file enrolment method and system
KR20240167923A (ko) 실시간 데이터의 예비 처리 및 검증
CN114529285A (zh) 数字货币支付方法、服务器、系统及介质
US11663576B2 (en) Methods and apparatus for initiating a payment transaction by a missed call
TWI923235B (zh) 支付額度提升的方法、裝置、設備及存儲介質
CN116468432B (zh) 订单的处理方法、装置、设备和介质
US20260073377A1 (en) Microtransactions for web 3.0 and metaverse

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24947784

Country of ref document: EP

Kind code of ref document: A1