Transaction result data processing method, device, equipment and storage medium

By building an order adjustment model and data sharding timed tasks, and selecting the retrieval time and frequency according to transaction characteristic parameters, the problem of the inability of transaction status to converge quickly in the existing technology is solved, and the fast and flexible retrieval and secure storage of transaction results are achieved.

CN115689754BActive Publication Date: 2025-09-26PING AN PAY ELECTRONIC PAYMENT CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202211392167.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-11-08
Publication Date
2025-09-26
Estimated Expiration
2042-11-08

AI Technical Summary

Technical Problem

Existing technologies cannot support more fine-grained transaction result retrieval rule configuration, resulting in the inability to quickly and accurately converge transaction status and unable to meet flexibility and speed requirements.

Method used

By building an order adjustment model, the transaction characteristic parameters are divided into merchant dimension, channel dimension, scenario dimension, product dimension and amount dimension, a scheduling strategy mapping relationship is constructed, the retrieval time and frequency are flexibly selected, and the data sharding timing task and blockchain encrypted storage are combined to achieve rapid convergence of transaction results.

Benefits of technology

It realizes the selection of different scheduling strategies according to transaction characteristics, quickly converges transaction status, meets the flexibility and speed requirements of the retrieval method, and improves data storage security and order adjustment efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115689754B_ABST
    Figure CN115689754B_ABST
Patent Text Reader

Abstract

The present application relates to the field of data processing and discloses a transaction result data processing method, apparatus, device, and storage medium. The method comprises: receiving transaction result retrieval data from a first business system; obtaining transaction characteristic parameters based on the transaction result retrieval data, inputting the transaction characteristic parameters into a pre-built order retrieval model, and obtaining a retrieval time and number of retrievals corresponding to the transaction result retrieval data; and issuing a transaction result retrieval request to a second business system based on the retrieval time and number of retrievals to obtain the retrieved transaction result. The transaction result data processing method provided in the embodiment of the present application can flexibly select different result retrieval strategies based on the different characteristics of the transaction order, so that the transaction status converges quickly and the user can obtain the transaction result as soon as possible.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a transaction result data processing method, apparatus, device and storage medium. Background Art

[0002] With the development of the Internet and e-commerce technologies, online shopping and online bill payments have become a way of consumption for many people. When payment companies conduct financial transactions with banking institutions, the bank side takes time to process the transaction. Therefore, the transaction status remains in the processing state from the time the payment company issues the transaction to the time the transaction result is actively retrieved or the bank side asynchronously notifies the transaction result. Payment companies usually actively retrieve transaction results on a regular basis in various business systems, and automatically converge the transaction status after obtaining the results. The transaction result retrieval method in the existing technology cannot support more fine-grained order adjustment rule configuration. The same transaction result retrieval strategy is adopted for transaction orders with different characteristics, which cannot enable users to quickly and accurately obtain transaction result data, and it is difficult to meet the flexibility and speed requirements of the retrieval method. Summary of the Invention

[0003] The disclosed embodiments provide a transaction result data processing method, apparatus, device, and storage medium. To provide a basic understanding of some aspects of the disclosed embodiments, the following is a brief summary. This summary is not intended to be a comprehensive review, identify key or important elements, or delineate the scope of protection for these embodiments. Its sole purpose is to present some concepts in a simplified form, serving as a prelude to the detailed description that follows.

[0004] In a first aspect, an embodiment of the present application provides a method for processing transaction result data, comprising:

[0005] Receiving transaction results and retrieving data from the first business system;

[0006] Obtain transaction characteristic parameters based on transaction result retrieval data, input the transaction characteristic parameters into the pre-built order adjustment model, and obtain the retrieval time and number of retrievals corresponding to the transaction result retrieval data;

[0007] A transaction result retrieval request is sent to the second business system according to the retrieval time and the retrieval number, and the retrieved transaction result is obtained.

[0008] In an optional embodiment, retrieving data based on the transaction result to obtain transaction characteristic parameters includes:

[0009] The transaction result is parsed and data is retrieved to obtain one or more transaction characteristic parameters including the scenario identifier, merchant membership number, channel identifier, product type identifier, and transaction amount of the transaction order.

[0010] In an optional embodiment, before inputting the transaction characteristic parameters into the pre-built order adjustment model, the process further includes:

[0011] Construct the user's transaction feature parameter set;

[0012] Divide the transaction feature parameter set into merchant dimension, channel dimension, scenario dimension, product dimension and amount dimension;

[0013] Construct a mapping relationship between each dimension and the scheduling strategy to obtain a constructed order model, where different scheduling strategies correspond to different call times and call times.

[0014] In an optional embodiment, constructing a mapping relationship between each dimension and a scheduling policy includes:

[0015] According to the merchant's corresponding membership level, build corresponding scheduling strategies for merchants with different membership levels;

[0016] Build scheduling strategies for different payment channels based on the payment channels corresponding to the transactions;

[0017] Build scheduling strategies for different payment scenarios based on the payment scenarios corresponding to the transactions;

[0018] Build scheduling strategies for different banking products based on the banking products corresponding to the transactions;

[0019] Based on the payment amount corresponding to the transaction, construct scheduling strategies corresponding to different payment amounts.

[0020] In an optional embodiment, it further includes:

[0021] According to the combination of different dimensions, a scheduling strategy corresponding to the combined dimensions is constructed.

[0022] In an optional embodiment, a transaction result retrieval request is sent to the second business system according to the retrieval time and the retrieval number to obtain the retrieved transaction result, including:

[0023] Store the transaction result retrieval data, retrieval time, and retrieval frequency into the order flow sheet;

[0024] Through the scheduled task that supports data sharding, the unprocessed transaction result retrieval data in the order flow table is pulled according to the retrieval time, and a transaction result retrieval request is sent to the second business system;

[0025] Determine whether the transaction result is successfully obtained. If the transaction result is successfully obtained, update the transaction result retrieval status to the completed status. If the transaction result is not successfully obtained, update the retrieval count and the next retrieval time, and store the updated retrieval count and retrieval time in the order flow table.

[0026] In an optional embodiment, after obtaining the retrieved transaction result, the method further includes:

[0027] Encrypt transaction results using a pre-set encryption algorithm;

[0028] Store the encrypted transaction results in the blockchain;

[0029] Receive transaction result query requests and obtain user identity information corresponding to the query requests;

[0030] Verify the user's identity information. When the verification is successful, obtain the encrypted transaction result data corresponding to the query request from the blockchain, decrypt the encrypted data, and send the decrypted data to the verified user for viewing;

[0031] When the verification fails, a prompt message indicating that the identity verification failed is sent.

[0032] In a second aspect, an embodiment of the present application provides a transaction result processing device, comprising:

[0033] A receiving module, configured to receive transaction result data from the first business system;

[0034] The retrieval strategy determination module is used to obtain transaction characteristic parameters based on the transaction result retrieval data, input the transaction characteristic parameters into the pre-built order retrieval model, and obtain the retrieval time and number of retrievals corresponding to the transaction result retrieval data;

[0035] The transaction result retrieval module is used to send a transaction result retrieval request to the second business system according to the retrieval time and the retrieval number, and obtain the retrieved transaction result.

[0036] In a third aspect, an embodiment of the present application provides a computer device comprising a memory and a processor, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor executes the transaction result data processing method provided in the above embodiment.

[0037] In a fourth aspect, an embodiment of the present application provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the transaction result data processing method provided in the above embodiment.

[0038] The technical solutions provided by the embodiments of the present disclosure may have the following beneficial effects:

[0039] According to the transaction result data processing method provided in the embodiment of the present application, after obtaining the transaction result retrieval data corresponding to the order, the transaction characteristic parameters can be parsed, and the retrieval time and retrieval number corresponding to the transaction result retrieval data can be obtained according to the different characteristic parameters of the transaction order and the pre-built order adjustment model. According to the characteristics of different transaction orders, the retrieval time and retrieval number corresponding to the order can be obtained through the model, and different scheduling strategies can be selected according to the characteristics of different transaction results. For example, important transaction results can be quickly and preferentially retrieved, so that the transaction status can converge quickly, allowing users to obtain transaction results as soon as possible, meeting the flexibility and speed requirements of the retrieval method.

[0040] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0042] Figure 1 is a diagram illustrating an implementation environment of a transaction result data processing method according to an exemplary embodiment;

[0043] Figure 2 is a diagram showing the internal structure of a computer device according to an exemplary embodiment;

[0044] Figure 3 is a flowchart illustrating a method for processing transaction result data according to an exemplary embodiment;

[0045] Figure 4 is a timing diagram illustrating a method for processing transaction result data according to an exemplary embodiment;

[0046] Figure 5 The figure is a schematic structural diagram of a device for processing transaction results according to an exemplary embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0048] It is understood that the terms "first," "second," and the like used herein may be used to describe various elements herein, but these elements are not limited by these terms. These terms are used only to distinguish a first element from another element. For example, a first field and an algorithm determination module may be referred to as a second field and an algorithm determination module, and similarly, a second field and an algorithm determination module may be referred to as a first field and an algorithm determination module, without departing from the scope of this application.

[0049] Figure 1 FIG. 1 is a diagram illustrating an implementation environment of a transaction result data processing method according to an exemplary embodiment. Figure 1 As shown, in this implementation environment, a server 110 and a terminal 120 are included.

[0050] Server 110 is a transaction result processing device, such as a computer used by technicians. Transaction result processing tools are installed on server 110. Terminal 120 is installed with an application required for transaction result processing. To obtain transaction results, a technician can issue a transaction result processing request to computer 110. This request carries a request identifier. Computer 110 receives the request and retrieves the transaction result data processing method stored there. The transaction result data processing method is then used to retrieve the transaction results.

[0051] It should be noted that the terminal 120 and the computer device 110 can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc., but are not limited thereto. The computer device 110 and the terminal 120 can be connected via Bluetooth, USB (Universal Serial Bus), or other communication connection methods, and this application does not impose any restrictions on this.

[0052] Figure 2 FIG. 1 is a diagram showing the internal structure of a computer device according to an exemplary embodiment. Figure 2 As shown, the computer device includes a processor, a non-volatile storage medium, a memory, and a network interface connected via a system bus. The non-volatile storage medium of the computer device stores an operating system, a database, and computer-readable instructions. The database may store a control information sequence. When the computer-readable instructions are executed by the processor, the processor may implement a transaction result data processing method. The processor of the computer device is used to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor may implement a transaction result data processing method. The network interface of the computer device is used to connect and communicate with the terminal. Those skilled in the art will understand that Figure 2The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0053] In the existing technology, payment companies usually retrieve transaction result data from various business systems at regular intervals and automatically converge the state after obtaining the transaction results. However, this overly fixed scheduling strategy has the following defects: First, it cannot support more fine-grained result retrieval rule configuration, such as the faster adjustment frequency of high-quality VIP merchants and the different adjustment rates of different bank products; second, each transaction corresponds to a transaction flow table and a scheduling, and regular query of the transaction flow table is stressful; third, for a sharded database and table system, the transaction records to be adjusted within a time period are distributed across multiple databases, and each scheduling requires checking multiple databases. The program design is unreasonable and needs to be improved; fourth, the original scheduled adjustment task does not support data sharding capabilities and can only be executed on a single machine, resulting in very low adjustment efficiency.

[0054] Based on this, an embodiment of the present application provides a transaction result data processing method. After obtaining the transaction result retrieval data corresponding to the order, it can parse the transaction characteristic parameters, and obtain the calculated retrieval time and number of retrievals based on the different characteristic parameters of the transaction order and the pre-built order retrieval model. Different result retrieval strategies can be flexibly selected through different transaction order characteristics to make the transaction status converge quickly, allowing users to obtain transaction results as soon as possible, meeting the flexibility and speed requirements of the retrieval method.

[0055] The following will be combined with the Figure 3 This section provides a detailed introduction to the transaction result data processing method provided in the embodiments of this application. This method can be implemented using a computer program and run on a data transmission device based on the von Neumann architecture. This computer program can be integrated into an application or run as a standalone tool application.

[0056] See Figure 3 , provides a flow chart of a transaction result data processing method according to an embodiment of the present application, such as Figure 3 As shown, the method of the embodiment of the present application may include the following steps:

[0057] S301 receives transaction result data from the first business system.

[0058] Before executing step S301, the process also includes determining whether to retrieve the transaction results through the first business system. The first business system refers to a payment system. For example, if the first business system is the Alipay payment platform, a user initiates a cash transaction through the Alipay payment platform, or if the first business system is the WeChat payment platform, a user initiates a cash transaction through the WeChat payment platform. After initiating the transaction with the bank, the first business system obtains the current transaction processing status. If the transaction processing status is "processing," it determines that the transaction result data needs to be retrieved from the bank system.

[0059] Furthermore, after the first business system determines that a transaction result needs to be retrieved, it synchronizes the retrieved transaction result data for the transaction to the retrieval module. The retrieved transaction result data includes transaction scenario data, merchant data, transaction channel data, product type data, transaction amount data, etc. After receiving the transaction result data from the first business system, the retrieval module selects different scheduling strategies based on the transaction characteristics.

[0060] S302 obtains transaction characteristic parameters based on the transaction result retrieval data, inputs the transaction characteristic parameters into a pre-built order adjustment model, and obtains the retrieval time and number of retrievals corresponding to the transaction result retrieval data.

[0061] In a possible implementation, before inputting the transaction feature parameters into the pre-built order adjustment model, the order adjustment model is also constructed.

[0062] Specifically, a user transaction feature parameter set is constructed by collecting the transaction feature parameters of a large number of users within a preset time period to obtain the transaction feature parameter set. For example, the feature parameters of all transacting users over the past six months can be collected. The feature parameters include the user's scenario identifier, merchant membership number, channel identifier, product type identifier, and transaction amount, etc., to obtain the transaction feature parameter set.

[0063] The transaction feature parameter set is divided into merchant dimension, channel dimension, scenario dimension, product dimension and amount dimension, and a mapping relationship between each dimension and the scheduling strategy is constructed to obtain a constructed order adjustment model, in which different scheduling strategies correspond to different retrieval times and retrieval times.

[0064] In an optional implementation, a different scheduling strategy is configured for each dimension, and the correspondence between the dimension and the scheduling strategy is stored in a mapping table.

[0065] Specifically, we build scheduling strategies for merchants of different membership levels based on their corresponding membership levels. For example, the transaction processing result retrieval time for ordinary merchants is 3 minutes, with a maximum of 5 retrievals; the transaction processing result retrieval time for VIP merchants is 2 minutes, with a maximum of 6 retrievals; and the transaction processing result retrieval time for super VIP merchants is 1 minute, with an unlimited number of retrievals. This solution allows VIP merchants to schedule orders more quickly.

[0066] Based on the payment channel corresponding to the transaction, a scheduling strategy is constructed for each payment channel. For example, the retrieval time for Bank of China transaction processing results is 3 minutes, with a maximum of 5 retrievals; the retrieval time for China CITIC Bank transaction processing results is 2 minutes, with a maximum of 6 retrievals; and the retrieval time for China Construction Bank transaction processing results is 1 minute, with an unlimited number of retrievals. This solution allows you to configure different scheduling strategies for different bank payment channels. For example, you can configure a higher retrieval frequency for banks with which merchants have a partnership, encouraging merchants to choose those banks for transactions.

[0067] Based on the payment scenarios corresponding to the transactions, we build scheduling policies tailored to each payment scenario. For example, the retrieval time for utility bill payments is 3 minutes, with a maximum of 5 retrievals; the retrieval time for product purchases is 2 minutes, with a maximum of 6 retrievals; and the retrieval time for remittances is 30 seconds, with an unlimited number of retrievals. By configuring different scheduling policies for different transaction scenarios, we can ensure faster result retrieval for scenarios requiring urgent results.

[0068] Based on the bank products corresponding to the transactions, construct scheduling strategies corresponding to different bank products. For example, if the transaction involves purchasing a bank's wealth management product, the corresponding transaction result retrieval time is 1 minute, and the maximum number of retrievals is 3 times. If the transaction involves products such as the bank's quick payment, the corresponding transaction result retrieval time is 20 seconds, and the maximum number of retrievals is unlimited.

[0069] Based on the corresponding payment amount of the transaction, a scheduling strategy is established for different payment amounts. For example, the larger the amount, the shorter the corresponding retrieval interval and the higher the retrieval frequency. For example, for transaction results under 1,000 yuan, the retrieval time is 3 minutes per retrieval, and the number of retrievals is 3 times. If the retrieval time reaches the limit and the retrieval data is still not returned, the system will not actively retrieve the data and will wait for the transaction result to be returned by the bank system. For transaction results over 10,000 yuan, the retrieval time is 1 minute per retrieval, and the number of retrievals is 5 times, increasing the retrieval frequency.

[0070] In an optional embodiment, it also includes constructing a scheduling strategy corresponding to the combination dimension based on the combination of different dimensions.

[0071] The above dimensions can be used individually or in combination. In one possible implementation, a scheduling policy for the combined dimensions can be configured. For example, if the VIP merchant conditions and the amount range conditions are met, the configured scheduling policy includes a retrieval time of once every 10 seconds, with an unlimited number of retrievals, further improving the retrieval rate. For example, if the VIP merchant conditions, scenario conditions, and payment channel conditions are met, the configured scheduling policy includes a retrieval time of once every 5 seconds, with an unlimited number of retrievals.

[0072] Those skilled in the art can set the scheduling strategies corresponding to different combination dimensions on their own, and the time parameters and number parameters in the scheduling strategies can be set according to actual needs, and the embodiments of the present application do not impose specific restrictions. For example, you can configure equal-length order adjustments, specify the number of order adjustments, and the time intervals between each order adjustment are equal. You can configure a specified time order adjustment configuration, specify different order adjustment time periods and the time intervals within each order adjustment time period. You can configure a custom order adjustment, and specify the order adjustment interval for each time.

[0073] After obtaining the established order adjustment model, the transaction result data is retrieved to obtain the transaction characteristic parameters. This involves parsing the transaction result data to obtain one or more transaction characteristic parameters, including the transaction order scenario identifier, merchant membership number, channel identifier, product type identifier, and transaction amount. The transaction characteristic parameters are input into the pre-built order adjustment model to obtain the corresponding retrieval time and number of retrievals for the transaction result retrieval data.

[0074] Specifically, if the transaction result data contains only one transaction characteristic parameter, this parameter is input into the order scheduling model to obtain the scheduling strategy corresponding to this parameter. If the transaction result data contains multiple transaction characteristic parameters in combination, the order scheduling model outputs the scheduling strategy corresponding to this combination. If the transaction result data contains multiple transaction characteristic parameters but no scheduling strategy corresponding to the combination dimension is matched, the order scheduling model outputs the solution with the fastest scheduling frequency.

[0075] S303 sends a transaction result retrieval request to the second business system according to the retrieval time and the retrieval number, and obtains the retrieved transaction result.

[0076] Specifically, after obtaining the retrieval time and number of retrievals, the transaction result retrieval data and the retrieval time and number of retrievals output by the model are stored in the order flow table; then, through a scheduled task that supports data sharding, the unprocessed data of the specified shard in the order flow table is pulled according to the retrieval time, and a transaction result retrieval request is issued to the second business system, where the second business system is a bank system.

[0077] Determine whether the transaction result was successfully obtained. If so, update the transaction result retrieval status to completed. If not, update the retrieval count and next retrieval time, and store the updated retrieval count and time in the order flow table. This allows for rapid convergence of various transaction statuses through unified order adjustments.

[0078] In one optional embodiment, after obtaining the retrieved transaction results, the transaction results are categorized and organized. For example, transaction results for the same scenario are stored in a list based on the scenario code of the transaction data, and transaction results for the same payment channel are stored in a list based on the payment channel identifier. The retrieved transaction result data is stored in the blockchain. The categorized transaction results can be stored in the blockchain, which not only improves the security of data storage but also facilitates user data query.

[0079] Specifically, the transaction result data is obtained and encrypted using a pre-set encryption algorithm. For example, encryption algorithms such as SM2, SM4, and SM9 are used to encrypt the data. In the SM9 identifier cipher, the identifier is the public key and can be used directly to encrypt the data. During decryption, the SM9 private key is generated to decrypt the data.

[0080] Optionally, different encryption levels can be assigned to different types of transaction results based on the categorized transaction results. For example, transactions with large amounts are assigned level 1 encryption, where all data is encrypted, and two encryption methods can be used for repeated encryption. Transactions with smaller amounts are assigned level 2 encryption, where only a portion of the data can be encrypted once. Alternatively, for important transactions, level 1 encryption can be used, while for more general transactions, level 2 encryption can be used. By using different encryption levels based on the transaction results' categorization, the security of important transaction data is further enhanced.

[0081] The encrypted transaction results are stored in the blockchain. If a user initiates a query request, the transaction result query request is received, and the user identity information corresponding to the query request is obtained. The user identity information is verified. If the verification is successful, the encrypted transaction result data corresponding to the query request is obtained from the blockchain, the encrypted data is decrypted, and the decrypted data is sent to the verified user for review. If the verification fails, a prompt message indicating that the authentication failed is sent. For example, the user's identity information is received and the user identity is checked to see if it belongs to the list of users with access rights. If the user has access rights, the authentication is successful.

[0082] By storing transaction results in the blockchain, the security of data storage can be improved and data can be prevented from being maliciously tampered with.

[0083] In order to facilitate understanding of the transaction result data processing method provided in the embodiment of the present application, the following Figure 4 Further explanation: Figure 4 is a timing diagram showing a method for processing transaction result data according to an exemplary embodiment. Figure 4 As shown, the transaction result data processing method includes the following steps:

[0084] First, the payment system determines whether the transaction result needs to be retrieved and obtains the processing status of the transaction result. If the transaction status is in progress, it determines that the transaction result needs to be retrieved, that is, the order needs to be adjusted. The transaction result data is synchronized to the order adjustment module.

[0085] Furthermore, the order adjustment module saves the transaction result retrieval data, obtains transaction characteristic parameters based on the transaction result retrieval data, inputs the transaction characteristic parameters into the pre-built order adjustment model, and obtains the retrieval time and number of retrievals corresponding to the transaction result retrieval data; based on the retrieval time and number of retrievals, a transaction result retrieval request is sent to the second business system, and the query interface is called to obtain the transaction result returned by the business system on the bank side.

[0086] Finally, save the returned transaction result, which can be saved in the blockchain.

[0087] After the unified order adjustment module of this application receives the transaction result retrieval data from the business system through the message queue, it matches the transaction result retrieval data with the configured scheduling strategy. After matching the corresponding order adjustment rules, it obtains the retrieval time and the number of retrievals, and puts the transaction result retrieval data and the calculated order adjustment time into the order adjustment flow table. Subsequently, through the timed task that supports data sharding in the unified order adjustment module, each time the unprocessed data of the specified shard in the order adjustment flow table is pulled to initiate an order adjustment request. If the order adjustment result is a final state, the order adjustment flow is updated to completion. Otherwise, the number of order adjustments and the next order adjustment time calculated according to the scheduling rules are updated, thereby achieving rapid convergence of various transaction states through unified order adjustment.

[0088] This method aims to achieve rapid transaction status convergence, allowing users to quickly obtain transaction results. It allows for flexible rule switching, enabling immediate deployment, making it more flexible than previous scheduled order adjustments. Each business system only needs to focus on its own order adjustment business data, eliminating the need to re-implement its own scheduled order adjustment logic, improving development efficiency. It also supports data sharding, significantly improving order adjustment efficiency. It also supports the use of sharded tables and databases in business systems, significantly enhancing performance and scalability.

[0089] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0090] See Figure 5 , which shows a schematic diagram of the structure of a transaction result data processing device provided by an exemplary embodiment of the present application. Figure 5 As shown, the transaction result processing device can be integrated into the above-mentioned computer device 110, and can specifically include a receiving module 501, a retrieval strategy determination module 502 and a transaction result retrieval module 503.

[0091] Receiving module 501, used to receive transaction result data from the first business system;

[0092] The retrieval strategy determination module 502 is used to obtain transaction characteristic parameters based on the transaction result retrieval data, input the transaction characteristic parameters into a pre-built order retrieval model, and obtain the retrieval time and number of retrievals corresponding to the transaction result retrieval data;

[0093] The transaction result retrieval module 503 is configured to send a transaction result retrieval request to the second business system according to the retrieval time and the retrieval number, and obtain the retrieved transaction result.

[0094] In an optional embodiment, the retrieval strategy determination module 502 is specifically used to parse the transaction result and retrieve data to obtain one or more transaction feature parameters of the transaction order, including the scenario identifier, merchant membership number, channel identifier, product type identifier, and transaction amount.

[0095] In an optional embodiment, it further includes a model building module for building a transaction feature parameter set of a user;

[0096] Divide the transaction feature parameter set into merchant dimension, channel dimension, scenario dimension, product dimension and amount dimension;

[0097] Construct a mapping relationship between each dimension and the scheduling strategy to obtain a constructed order model, where different scheduling strategies correspond to different call times and call times.

[0098] In an optional embodiment, the model building module is used to build scheduling strategies corresponding to merchants of different membership levels according to the membership levels corresponding to the merchants;

[0099] Build scheduling strategies for different payment channels based on the payment channels corresponding to the transactions;

[0100] Build scheduling strategies for different payment scenarios based on the payment scenarios corresponding to the transactions;

[0101] Build scheduling strategies for different banking products based on the banking products corresponding to the transactions;

[0102] Based on the payment amount corresponding to the transaction, construct scheduling strategies corresponding to different payment amounts.

[0103] In an optional embodiment, the model building module is further configured to build a scheduling strategy corresponding to the combination dimension based on the combination of different dimensions.

[0104] In an optional embodiment, the transaction result retrieval module is used to store the transaction result retrieval data as well as the retrieval time and retrieval number in the order flow table;

[0105] Through the scheduled task that supports data sharding, the unprocessed transaction result retrieval data in the order flow table is pulled according to the retrieval time, and a transaction result retrieval request is sent to the second business system;

[0106] Determine whether the transaction result is successfully obtained. If the transaction result is successfully obtained, update the transaction result retrieval status to the completed status. If the transaction result is not successfully obtained, update the retrieval count and the next retrieval time, and store the updated retrieval count and retrieval time in the order flow table.

[0107] In an optional embodiment, a data storage module is further included, which is used to encrypt the transaction results using a preset encryption algorithm;

[0108] Store the encrypted transaction results in the blockchain;

[0109] Receive transaction result query requests and obtain user identity information corresponding to the query requests;

[0110] Verify the user's identity information. When the verification is successful, obtain the encrypted transaction result data corresponding to the query request from the blockchain, decrypt the encrypted data, and send the decrypted data to the verified user for viewing;

[0111] When the verification fails, a prompt message indicating that the identity verification failed is sent.

[0112] According to the transaction result processing device provided in the embodiment of the present application, after obtaining the transaction result retrieval data corresponding to the order, it can parse the transaction characteristic parameters, and obtain the calculated retrieval time and number of retrievals based on the different characteristic parameters of the transaction order and the pre-built order retrieval model. Different result retrieval strategies can be flexibly selected according to different transaction order characteristics, so that the transaction status can converge quickly, allowing users to obtain transaction results as soon as possible, meeting the flexibility and speed requirements of the retrieval method.

[0113] It should be noted that the transaction result data processing device provided in the above embodiment, when executing the transaction result data processing method, is merely illustrated by the division of the aforementioned functional modules. In actual applications, the aforementioned functions can be assigned to different functional modules as needed, i.e., the internal structure of the device can be divided into different functional modules to perform all or part of the functions described above. Furthermore, the transaction result data processing device provided in the above embodiment and the transaction result data processing method embodiment are based on the same concept. The implementation process is detailed in the method embodiment and will not be further described here.

[0114] In one embodiment, a computer device is proposed, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are implemented: receiving transaction result retrieval data from a first business system; obtaining transaction characteristic parameters based on the transaction result retrieval data, inputting the transaction characteristic parameters into a pre-built order adjustment model, and obtaining a retrieval time and number of retrievals corresponding to the transaction result retrieval data; and sending a transaction result retrieval request to a second business system based on the retrieval time and number of retrievals to obtain the retrieved transaction results.

[0115] In an optional embodiment, retrieving data based on the transaction result to obtain transaction characteristic parameters includes:

[0116] The transaction result is parsed and data is retrieved to obtain one or more transaction characteristic parameters including the scenario identifier, merchant membership number, channel identifier, product type identifier, and transaction amount of the transaction order.

[0117] In an optional embodiment, before inputting the transaction characteristic parameters into the pre-built order adjustment model, the process further includes:

[0118] Construct the user's transaction feature parameter set;

[0119] Divide the transaction feature parameter set into merchant dimension, channel dimension, scenario dimension, product dimension and amount dimension;

[0120] Construct a mapping relationship between each dimension and the scheduling strategy to obtain a constructed order model, where different scheduling strategies correspond to different call times and call times.

[0121] In an optional embodiment, constructing a mapping relationship between each dimension and a scheduling policy includes:

[0122] According to the merchant's corresponding membership level, build corresponding scheduling strategies for merchants with different membership levels;

[0123] Build scheduling strategies for different payment channels based on the payment channels corresponding to the transactions;

[0124] Build scheduling strategies for different payment scenarios based on the payment scenarios corresponding to the transactions;

[0125] Build scheduling strategies for different banking products based on the banking products corresponding to the transactions;

[0126] Based on the payment amount corresponding to the transaction, construct scheduling strategies corresponding to different payment amounts.

[0127] In an optional embodiment, it further includes:

[0128] According to the combination of different dimensions, a scheduling strategy corresponding to the combined dimensions is constructed.

[0129] In an optional embodiment, a transaction result retrieval request is sent to the second business system according to the retrieval time and the retrieval number to obtain the retrieved transaction result, including:

[0130] Store the transaction result retrieval data, retrieval time, and retrieval frequency into the order flow sheet;

[0131] Through the scheduled task that supports data sharding, the unprocessed transaction result retrieval data in the order flow table is pulled according to the retrieval time, and a transaction result retrieval request is sent to the second business system;

[0132] Determine whether the transaction result is successfully obtained. If the transaction result is successfully obtained, update the transaction result retrieval status to the completed status. If the transaction result is not successfully obtained, update the retrieval count and the next retrieval time, and store the updated retrieval count and retrieval time in the order flow table.

[0133] In an optional embodiment, after obtaining the retrieved transaction result, the method further includes:

[0134] Encrypt transaction results using a pre-set encryption algorithm;

[0135] Store the encrypted transaction results in the blockchain;

[0136] Receive transaction result query requests and obtain user identity information corresponding to the query requests;

[0137] Verify the user's identity information. When the verification is successful, obtain the encrypted transaction result data corresponding to the query request from the blockchain, decrypt the encrypted data, and send the decrypted data to the verified user for viewing;

[0138] When the verification fails, a prompt message indicating that the identity verification failed is sent.

[0139] In one embodiment, a storage medium storing computer-readable instructions is proposed. When the computer-readable instructions are executed by one or more processors, the one or more processors perform the following steps: receiving transaction result retrieval data from a first business system; obtaining transaction feature parameters based on the transaction result retrieval data, inputting the transaction feature parameters into a pre-built order retrieval model, and obtaining the retrieval time and number of retrievals corresponding to the transaction result retrieval data; and sending a transaction result retrieval request to a second business system based on the retrieval time and number of retrievals to obtain the retrieved transaction results.

[0140] In an optional embodiment, retrieving data based on the transaction result to obtain transaction characteristic parameters includes:

[0141] The transaction result is parsed and data is retrieved to obtain one or more transaction characteristic parameters including the scenario identifier, merchant membership number, channel identifier, product type identifier, and transaction amount of the transaction order.

[0142] In an optional embodiment, before inputting the transaction characteristic parameters into the pre-built order adjustment model, the process further includes:

[0143] Construct the user's transaction feature parameter set;

[0144] Divide the transaction feature parameter set into merchant dimension, channel dimension, scenario dimension, product dimension and amount dimension;

[0145] Construct a mapping relationship between each dimension and the scheduling strategy to obtain a constructed order model, where different scheduling strategies correspond to different call times and call times.

[0146] In an optional embodiment, constructing a mapping relationship between each dimension and a scheduling policy includes:

[0147] According to the merchant's corresponding membership level, build corresponding scheduling strategies for merchants with different membership levels;

[0148] Build scheduling strategies for different payment channels based on the payment channels corresponding to the transactions;

[0149] Build scheduling strategies for different payment scenarios based on the payment scenarios corresponding to the transactions;

[0150] Build scheduling strategies for different banking products based on the banking products corresponding to the transactions;

[0151] Based on the payment amount corresponding to the transaction, construct scheduling strategies corresponding to different payment amounts.

[0152] In an optional embodiment, it further includes:

[0153] According to the combination of different dimensions, a scheduling strategy corresponding to the combined dimensions is constructed.

[0154] In an optional embodiment, a transaction result retrieval request is sent to the second business system according to the retrieval time and the retrieval number to obtain the retrieved transaction result, including:

[0155] Store the transaction result retrieval data, retrieval time, and retrieval frequency into the order flow sheet;

[0156] Through the scheduled task that supports data sharding, the unprocessed transaction result retrieval data in the order flow table is pulled according to the retrieval time, and a transaction result retrieval request is sent to the second business system;

[0157] Determine whether the transaction result is successfully obtained. If the transaction result is successfully obtained, update the transaction result retrieval status to the completed status. If the transaction result is not successfully obtained, update the retrieval count and the next retrieval time, and store the updated retrieval count and retrieval time in the order flow table.

[0158] In an optional embodiment, after obtaining the retrieved transaction result, the method further includes:

[0159] Encrypt transaction results using a pre-set encryption algorithm;

[0160] Store the encrypted transaction results in the blockchain;

[0161] Receive transaction result query requests and obtain user identity information corresponding to the query requests;

[0162] Verify the user's identity information. When the verification is successful, obtain the encrypted transaction result data corresponding to the query request from the blockchain, decrypt the encrypted data, and send the decrypted data to the verified user for viewing;

[0163] When the verification fails, a prompt message indicating that the identity verification failed is sent.

[0164] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0165] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0166] The above embodiments merely illustrate several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. A transaction result data processing method, characterized in that: include: Receiving transaction results and retrieving data from the first business system; Parsing the transaction result and retrieving data to obtain one or more transaction characteristic parameters of the transaction order, including a scenario identifier, a merchant membership number, a channel identifier, a product type identifier, and a transaction amount; Construct a user's transaction feature parameter set; divide the transaction feature parameter set into merchant dimension, channel dimension, scenario dimension, product dimension, and amount dimension; construct a mapping relationship between each dimension and the scheduling strategy to obtain a constructed order adjustment model, wherein different scheduling strategies correspond to different retrieval times and retrieval times; input the transaction feature parameters into the pre-constructed order adjustment model to obtain the retrieval time and retrieval times corresponding to the transaction result retrieval data; issuing a transaction result retrieval request to the second business system based on the retrieval time and retrieval frequency, and obtaining the retrieved transaction result; storing the transaction result retrieval data, the retrieval time, and the retrieval frequency in a transaction flow table; and pulling unprocessed transaction result retrieval data from the transaction flow table according to the retrieval time through a scheduled task that supports data sharding, and issuing a transaction result retrieval request to the second business system; Determine whether the transaction result is successfully obtained. If the transaction result is successfully obtained, update the transaction result retrieval status to the completed status. If the transaction result is not successfully obtained, update the retrieval count and the next retrieval time, and store the updated retrieval count and retrieval time in the order flow table.

2. The method according to claim 1, characterized in that Construct a mapping relationship between each dimension and the scheduling strategy, including: According to the merchant's corresponding membership level, build corresponding scheduling strategies for merchants with different membership levels; Build scheduling strategies for different payment channels based on the payment channels corresponding to the transactions; Build scheduling strategies for different payment scenarios based on the payment scenarios corresponding to the transactions; Build scheduling strategies for different banking products based on the banking products corresponding to the transactions; Based on the payment amount corresponding to the transaction, construct scheduling strategies corresponding to different payment amounts.

3. The method according to claim 1, characterized in that Also includes: According to the combination of different dimensions, a scheduling strategy corresponding to the combined dimensions is constructed.

4. The method according to claim 1, wherein After obtaining the retrieved transaction results, it also includes: Encrypting the transaction result using a preset encryption algorithm; Store the encrypted transaction results in the blockchain; Receive the transaction result query request and obtain user identity information corresponding to the query request; Verify the user's identity information. If the verification is successful, obtain the encrypted transaction result data corresponding to the query request from the blockchain, decrypt the encrypted data, and send the decrypted data to the verified user for review; When the verification fails, a prompt message indicating that the identity verification failed is sent.

5. A transaction result data processing device, characterized in that: include: A receiving module, configured to receive transaction result data from the first business system; A retrieval strategy determination module is configured to parse the transaction result retrieval data to obtain one or more transaction feature parameters of the transaction order, including the scenario identifier, merchant membership number, channel identifier, product type identifier, and transaction amount; construct a user's transaction feature parameter set; divide the transaction feature parameter set into merchant dimension, channel dimension, scenario dimension, product dimension, and amount dimension; construct a mapping relationship between each dimension and the scheduling strategy to obtain a constructed order adjustment model, wherein different scheduling strategies correspond to different retrieval times and retrieval times; input the transaction feature parameters into the pre-constructed order adjustment model to obtain the retrieval time and retrieval times corresponding to the transaction result retrieval data; The transaction result retrieval module is configured to send a transaction result retrieval request to the second business system based on the retrieval time and retrieval frequency to obtain the retrieved transaction result; the module stores the transaction result retrieval data, the retrieval time, and the retrieval frequency in a transaction flow table; and through a scheduled task that supports data sharding, pulls the unprocessed transaction result retrieval data in the transaction flow table according to the retrieval time, and sends a transaction result retrieval request to the second business system; Determine whether the transaction result is successfully obtained. If the transaction result is successfully obtained, update the transaction result retrieval status to the completed status. If the transaction result is not successfully obtained, update the retrieval count and the next retrieval time, and store the updated retrieval count and retrieval time in the order flow table.

6. A computer device comprising a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor executes the transaction result data processing method according to any one of claims 1 to 4.

7. A storage medium storing computer-readable instructions, wherein when the computer-readable instructions are executed by one or more processors, the one or more processors execute the transaction result data processing method according to any one of claims 1 to 4.

Citation Information

Patent Citations

  • Business approval method and device

    CN112184154A

  • Transaction data processing method and device, storage medium and server

    CN112346886A