Transaction method, device, non-volatile storage medium, and electronic device
By obtaining and processing transaction request information and calling the interface of the transaction tool to adjust the amount of virtual resources, the problem of asset loss caused by inconsistent payment status in multi-tool transactions is solved, ensuring the consistency and security of the payment status.
Patent Information
- Application Number
- CN202411706734.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-26
- Publication Date
- 2025-09-30
- Estimated Expiration
- 2044-11-26
AI Technical Summary
When multiple payment tools are involved in a transaction, if some payment tools succeed while others fail, the funds cannot be restored to the state before the transfer, resulting in capital loss.
By obtaining the user's transaction request information, calling the first transaction interface of each transaction tool, determining the first transaction result based on the response result, and calling the second transaction interface to adjust the virtual resource amount based on the first transaction result, including confirming the transaction interface and canceling the transaction interface, to ensure the consistency of the payment status.
It achieves consistency in payment status across all payment tools, avoids capital losses during transactions, and reduces customer complaint rates.
Smart Images

Figure CN119624444B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of online payment, and more specifically, to a transaction method, device, non-volatile storage medium, and electronic device. Background Art
[0002] When multiple payment methods are involved in a payment, some payment methods may succeed while others fail. After a successful payment, funds are transferred. If other payment methods fail and need to be rolled back, the funds may not be restored to their pre-transfer state, resulting in asset loss.
[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention
[0004] The embodiments of the present application provide a transaction method, device, non-volatile storage medium and electronic device to at least solve the technical problem of asset loss caused by inconsistent payment status between multiple transaction tools in a transaction.
[0005] According to one aspect of an embodiment of the present application, a transaction method is provided, including: obtaining transaction request information of a user, calling a first transaction interface of each transaction tool from a tool set based on the transaction request information, wherein the transaction request information includes the transaction tool information selected by the user, the virtual resource volume of the transaction, and the transaction type, the transaction type including payment, refund, freeze, unfreeze, and cancellation, the first transaction interface is used to pre-occupy the virtual resource volume in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; jointly determining a first transaction result based on a response result returned by each first transaction interface, wherein the first transaction result includes a successful transaction and a failed transaction, and the response result includes a successful response and a failed response; determining a second transaction interface to be called based on the first transaction result, calling the second transaction interface of each tool to adjust the pre-occupied virtual resource volume, wherein the second transaction interface includes a confirmed transaction interface and a cancelled transaction interface, the confirmed transaction interface is used to execute a transaction strategy corresponding to the transaction type, and the cancelled transaction interface is used to roll back the transaction status.
[0006] Optionally, the first transaction interface corresponding to each transaction tool and transaction type is called from the tool set based on the transaction request information. The method also includes: obtaining preferential rule information, judging whether the transaction meets the preferential rules, and if the preferential rules are met, subtracting the preferential virtual resource amount from the virtual resource amount of the transaction, and updating the virtual resource amount corresponding to each transaction tool; based on the virtual resource amount corresponding to each transaction tool, pre-occupying the virtual resource amount in each transaction tool.
[0007] Optionally, before jointly determining the first transaction result based on the response results returned by each first transaction interface, the method also includes: for each transaction tool, when the pre-occupation result is a successful pre-occupation, determining the response result as a successful response; for each transaction tool, when the pre-occupation result is a failed pre-occupation, determining the response result as a failed response; for each transaction tool, when the pre-occupation result is a response timeout, determining the response result as a failed response.
[0008] Optionally, jointly determining the first transaction result based on the response results returned by each first transaction interface includes: when the response results of each transaction tool are all successful responses, determining the first transaction result as a successful transaction; when the response result of any transaction tool is a failed response, determining the first transaction result as a failed transaction.
[0009] Optionally, based on the first transaction result, the second transaction interface to be called is determined, and calling the second transaction interface of each tool to adjust the reserved virtual resource amount includes: when the first transaction result is a successful transaction, calling the confirmation transaction interface of each transaction tool; when the first transaction result is a failed transaction, calling the cancellation transaction interface of each transaction tool.
[0010] Optionally, after calling the transaction cancellation interface of each trading tool, the method also includes: releasing the pre-occupation of the virtual resources pre-occupied in each trading tool; obtaining the call result returned by the transaction cancellation interface, and displaying the transaction result to the user when the transaction cancellation interface of each trading tool is successfully called.
[0011] Optionally, before calling the transaction confirmation interface of each trading tool, the method also includes: obtaining preferential rule information to determine whether the transaction meets the preferential rules; if the preferential rules are met, subtracting the preferential virtual resource amount from the virtual resource amount of the transaction, and updating the virtual resource amount and preferential usage status corresponding to each trading tool.
[0012] Optionally, after calling the transaction confirmation interface of each trading tool, the method also includes: when the preferential usage status is successfully updated, executing corresponding transaction strategies on the pre-occupied virtual resources in each trading tool according to the virtual resource volume corresponding to each trading tool, and adjusting the status of the pre-occupied virtual resources; obtaining the call result returned by the transaction confirmation interface, and displaying the transaction result to the user when the transaction confirmation interface of each trading tool is successfully called.
[0013] Optionally, after calling the second transaction interface of each tool, the method further includes: if calling the second transaction interface of each tool fails, cyclically calling the second transaction interface of each tool that failed to be called until all transaction tools are successfully called.
[0014] According to another aspect of an embodiment of the present application, a transaction device is also provided, including: an acquisition module for acquiring the transaction request information of the user, and calling the first transaction interface of each transaction tool from the tool set based on the transaction request information, wherein the transaction request information includes the transaction tool information selected by the user, the virtual resource amount of the transaction, and the transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancellation, and the first transaction interface is used to pre-occupy the virtual resource amount in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; a determination module for jointly determining the first transaction result based on the response results returned by each first transaction interface, wherein the first transaction result includes transaction success and transaction failure, and the response result includes response success and response failure; a calling module for determining the second transaction interface to be called based on the first transaction result, and calling the second transaction interface of each tool to adjust the pre-occupied virtual resource amount, wherein the second transaction interface includes a transaction confirmation interface and a transaction cancellation interface, the transaction confirmation interface is used to execute the transaction strategy corresponding to the transaction type, and the transaction cancellation interface is used to roll back the transaction status.
[0015] According to another aspect of an embodiment of the present application, a non-volatile storage medium is provided, in which a program is stored. When the program is executed, a device where the non-volatile storage medium is located is controlled to execute a transaction method.
[0016] According to another aspect of an embodiment of the present application, an electronic device is provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the transaction method is executed when the program is run.
[0017] According to another aspect of an embodiment of the present application, a computer program product is provided, including a computer program, which implements a transaction method when executed by a processor.
[0018] In an embodiment of the present application, a method is adopted in which transaction request information of a user is obtained, and a first transaction interface of each transaction tool is called from a tool set based on the transaction request information, wherein the transaction request information includes the transaction tool information selected by the user, the virtual resource amount of the transaction, and the transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancellation. The first transaction interface is used to pre-occupy the virtual resource amount in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; a first transaction result is jointly determined based on the response results returned by each first transaction interface, wherein the first transaction result includes transaction success and transaction failure, and the response result includes response success and response failure; based on the first transaction result, a second transaction interface to be called is determined, and the second transaction interface of each tool is called to adjust the pre-occupied virtual resource amount, wherein the second transaction interface includes a transaction confirmation interface and a transaction cancellation interface, wherein the transaction confirmation interface is used to execute the transaction policy corresponding to the transaction type, and the transaction cancellation interface is used to roll back the transaction status. By dividing the transaction process into two stages, the purpose of ensuring the consistency of the payment status of each payment tool is achieved, thereby achieving the technical effect of avoiding transaction capital loss, and further solving the technical problem of capital loss caused by inconsistent payment status between multiple transaction tools in the transaction. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:
[0020] Figure 1 This is a schematic diagram of the structure of a computer terminal (mobile device) provided according to an embodiment of the present application;
[0021] Figure 2 This is a flow chart of a transaction method provided according to an embodiment of the present application;
[0022] Figure 3 This is a schematic diagram of calling a first transaction interface according to an embodiment of the present application;
[0023] Figure 4 This is a schematic diagram of a process after calling a first transaction interface according to an embodiment of the present application;
[0024] Figure 5 This is a flow chart of calling a first transaction interface for payment according to an embodiment of the present application;
[0025] Figure 6 This is a flow chart of calling a first transaction interface for a refund transaction type according to an embodiment of the present application;
[0026] Figure 7This is a flow chart of calling a first transaction interface with a frozen transaction type according to an embodiment of the present application;
[0027] Figure 8 This is a flow chart of calling a first transaction interface with a transaction type of unfreeze according to an embodiment of the present application;
[0028] Figure 9 This is a schematic diagram of a transaction confirmation interface for calling various transaction tools according to an embodiment of the present application;
[0029] Figure 10 1 is a schematic diagram of a transaction cancellation interface for calling various transaction tools according to an embodiment of the present application;
[0030] Figure 11 This is a flow chart of calling a transaction cancellation interface according to an embodiment of the present application;
[0031] Figure 12 This is a flow chart of calling a transaction cancellation interface according to an embodiment of the present application;
[0032] Figure 13 This is a flow chart of calling a transaction confirmation interface according to an embodiment of the present application;
[0033] Figure 14 This is a flow chart of calling a transaction confirmation interface according to an embodiment of the present application;
[0034] Figure 15 This is a schematic diagram of a calling process of a second transaction interface provided according to an embodiment of the present application;
[0035] Figure 16 It is a structural diagram of a transaction device provided according to an embodiment of the present invention. DETAILED DESCRIPTION
[0036] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.
[0037] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0038] When multiple payment methods are involved in a payment, some payment methods may succeed while others fail. From the perspective of discounts, after a successful payment, funds will be transferred. If other payment methods fail and need to be refunded, the funds may not be restored to the state before the transfer, which will cause asset loss. For example, when discounts are used as a secondary payment method, they cannot be used independently without the primary payment method. This means that when discounts are used in payments, they will inevitably be used in conjunction with other payment methods. If other payment methods fail and need to be refunded, coupons, etc. may not be restored to the state before the transfer, which will cause asset loss.
[0039] In order to solve this problem, relevant solutions are provided in the embodiments of the present application, which are described in detail below.
[0040] According to an embodiment of the present application, a method embodiment of a transaction method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0041] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal (or mobile device) for implementing the transaction method is shown in FIG. Figure 1As shown, the computer terminal 10 (or mobile device 10) may include one or more (illustrated as 102a, 102b, ..., 102n) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.
[0042] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry". The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuitry may be a single independent processing module, or may be incorporated in whole or in part into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).
[0043] Memory 104 can be used to store software programs and modules for application software, such as the program instructions / data storage device corresponding to the transaction method in the embodiments of the present application. Processor 102 executes the software programs and modules stored in memory 104 to execute various functional applications and data processing, thereby implementing the aforementioned transaction method. Memory 104 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 may further include memory remotely located relative to processor 102, and such remote memory may be connected to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0044] The transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.
[0045] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).
[0046] In the above operating environment, the embodiment of the present application provides a transaction method, such as Figure 2 As shown, the method includes the following steps:
[0047] Step S202: Obtain the transaction request information of the user, and call the first transaction interface of each transaction tool from the tool set based on the transaction request information. The transaction request information includes the transaction tool information selected by the user, the virtual resource volume of the transaction, and the transaction type. The transaction type includes payment, refund, freeze, unfreeze, and cancellation. The first transaction interface is used to pre-occupy the virtual resource volume in each transaction tool. The type of the first transaction interface corresponds to the transaction type of each transaction tool.
[0048] Optionally, Figure 3 A schematic diagram of calling the first transaction interface is shown, such as Figure 3 As shown, when an asset exchange occurs, the trading system receives the user's transaction request information and calls the first transaction interface (loan, freeze, and unfreeze) (i.e., payment, refund, freeze, unfreeze, and cancellation) interface for all trading instruments involved in the transaction. Trading instruments include preferential payment instruments (equity assets).
[0049] Optionally, Figure 4 A flow chart after calling the first transaction interface is shown, Figure 4As shown in the figure, the process is divided into two main parts: main transaction processing and branch transaction processing. The process begins at the "Start" node and first enters the main transaction processing phase. During this phase, the system inserts a main transaction record and sets its status to "INIT." Subsequently, the system locks the main transaction's resources to ensure data consistency and integrity. If the lock is successful, the system inserts a branch transaction record and also sets its status to "INIT." Next, the system waits for the branch transaction to complete. If the branch transaction also successfully locks the resources, the system inserts a transaction document table record and sets its status to "INIT." During the branch transaction processing phase, the system first locks the main transaction, requiring the main transaction to be in the "INIT" state. If the lock is successful, the system calculates the transaction amount and determines whether the asset (i.e., the virtual resource quantity) is available. If the asset is available, the system updates the transaction document table's status from "INIT" to "TRY FINISH" and inserts a branch record with its instruction status set to "INIT." If the asset is unavailable, the process terminates immediately. Finally, the system assembles and returns the information, completing the entire transaction processing process. The entire process ensures the atomicity, consistency, isolation, and persistence of transactions through state control and resource locking.
[0050] Specifically, Figure 5 A flowchart of calling a first transaction interface with a transaction type of payment is shown. Figure 5As shown, the system first performs parameter verification to ensure that the input parameters meet the requirements. Next, the process enters the main transaction record locking phase to ensure that other transactions cannot modify the record during the update. The system then groups the records by asset ID for subsequent processing. During the asset locking phase, the system uses a SELECT FOR UPDATE WAIT lock to lock the relevant asset records to ensure data consistency when updating asset information. The system then accumulates the operation amount (i.e., virtual resource volume) and queries template information to calculate loan and credit funds (net amount, gross amount, and other indicators), as well as the available amount, including the balance, pre-occupied amount, stipulated balance, and the pre-net amount of the current transaction. If the asset is unavailable, the process terminates. If the asset is available, the system modifies the asset information and changes the transaction document status to TRY_FINISH. In another part of the process, the system checks the status of the main and branch transactions. If the main transaction status is INIT and a new main transaction record is required, the main transaction record is added; if not, the branch transaction record is directly added. If the branch transaction status is INIT, the branch transaction record is added; if not, parameter compliance is verified. If the parameters are in compliance, the system will query the transaction document information from the CD based on the asset exchange ID to determine whether the transaction document status is TRY_FINISH and the transaction amount is consistent. If they are consistent, the process will continue; if not, the process will end. Finally, the system will assemble the return information to complete the entire debit event processing process. Specifically, Figure 6 A flowchart of calling a first transaction interface with a transaction type of refund is shown. Figure 7 A flowchart of calling a first transaction interface with a transaction type of frozen is shown. Figure 8 A flow chart of calling a first transaction interface with a transaction type of unfreeze is shown.
[0051] In the technical solution provided in step S202, the first transaction interface corresponding to each transaction tool and transaction type is called from the tool set based on the transaction request information. The method also includes: obtaining preferential rule information, judging whether the transaction meets the preferential rules, and if the preferential rules are met, subtracting the preferential virtual resource amount from the virtual resource amount of the transaction, and updating the virtual resource amount corresponding to each transaction tool; based on the virtual resource amount corresponding to each transaction tool, pre-occupying the virtual resource amount in each transaction tool.
[0052] Step S204: determining a first transaction result based on the response results returned by each first transaction interface, wherein the first transaction result includes transaction success and transaction failure, and the response result includes response success and response failure.
[0053] Optionally, before jointly determining the first transaction result based on the response results returned by each first transaction interface, the method also includes: for each transaction tool, when the pre-occupation result is a successful pre-occupation, determining the response result as a successful response; for each transaction tool, when the pre-occupation result is a failed pre-occupation, determining the response result as a failed response; for each transaction tool, when the pre-occupation result is a response timeout, determining the response result as a failed response.
[0054] In the technical solution provided in step S204, the first transaction result is jointly determined based on the response results returned by each first transaction interface, including: when the response results of each transaction tool are all successful responses, the first transaction result is determined to be a successful transaction; when the response result of one transaction tool is a failed response, the first transaction result is determined to be a failed transaction.
[0055] Step S206: Determine the second transaction interface to be called based on the first transaction result, and call the second transaction interface of each tool to adjust the reserved virtual resource amount. The second transaction interface includes a confirmation transaction interface and a cancellation transaction interface. The confirmation transaction interface is used to execute the transaction strategy corresponding to the transaction type, and the cancellation transaction interface is used to roll back the transaction status.
[0056] In the technical solution provided in step S206, the second transaction interface to be called is determined based on the first transaction result, and calling the second transaction interface of each tool to adjust the reserved virtual resource amount includes: when the first transaction result is a successful transaction, calling the confirmation transaction interface of each transaction tool; when the first transaction result is a failed transaction, calling the cancellation transaction interface of each transaction tool.
[0057] Optionally, Figure 9 A schematic diagram showing the confirmation transaction interface for calling various trading tools is shown. Figure 10 A schematic diagram showing the calling of the transaction cancellation interface of each transaction tool.
[0058] Optionally, after calling the transaction cancellation interface of each trading tool, the method also includes: releasing the pre-occupation of the virtual resources pre-occupied in each trading tool; obtaining the call result returned by the transaction cancellation interface, and displaying the transaction result to the user when the transaction cancellation interface of each trading tool is successfully called.
[0059] Specifically, Figure 11 and Figure 12 The flowchart of calling the cancel transaction interface is shown as Figure 11 and Figure 12As shown, the system first determines whether an empty rollback occurred. If so, a record with the main transaction status set to ROLLBACK is inserted, and the process ends. If not, the process continues with the lock operation on the main transaction record, without waiting (NO WAIT). Next, the system verifies the legal status of the transaction document, main transaction, and branch transactions. If so, the process continues; if not, the process ends. If legal, the system groups the transaction documents by operation type and changes the status of the main and branch transactions from "INIT" to "SUCCESS." Next, the system groups the transactions by asset ID and performs an asset lock operation, also without waiting (SELECT FOR UPDATE NOWAIT). The system then accumulates the transaction amount and updates the asset information, releasing the pre-occupied virtual resource amount for each transaction instrument. After updating the asset information, the system changes the transaction document status from "INIT" or "TRY_FINISH" to "FAIL." Finally, the system assembles and returns the information, completing the cancellation process.
[0060] Optionally, before calling the transaction confirmation interface of each trading tool, the method further includes: obtaining preferential rule information to determine whether the transaction meets the preferential rules; if the preferential rules are met, subtracting the preferential virtual resource amount from the transaction virtual resource amount, and updating the virtual resource amount and preferential usage status corresponding to each trading tool. After calling the transaction confirmation interface of each trading tool, the method further includes: if the preferential usage status is successfully updated, based on the virtual resource amount corresponding to each trading tool, executing a corresponding transaction strategy on the pre-occupied virtual resource amount in each trading tool and adjusting the pre-occupied virtual resource amount status; obtaining the call result returned by the transaction confirmation interface, and if the call to the transaction confirmation interface of each trading tool is successful, displaying the transaction result to the user.
[0061] Specifically, Figure 13 and Figure 14 The flowchart of calling the confirmation transaction interface is shown as Figure 13 and Figure 14As shown, the main transaction record is first locked without waiting (NO WAIT). Next, the system verifies the legal status of the transaction document, main transaction, and branch transaction. If the status is legal, the process continues; if the status is illegal, the process ends. If the status is legal, the system groups the transaction documents according to the operation type and changes the status of the main and branch transactions from "INIT" to "SUCCESS." Subsequently, the system groups the assets according to their IDs and performs an asset lock operation, also without waiting (SELECT FOR UPDATE NO WAIT). Next, the system accumulates the transaction amount and determines whether the transaction meets the discount rules. If so, it modifies the coupon status (i.e., discount usage status) and updates the asset information (i.e., virtual resource quantity) corresponding to each transaction tool, including the modifier, reserved amount, balance, and coupon status.
[0062] Once the update is complete, the system will change the transaction document's status from "TRY_FINISH" to "SUCCESS." Next, the system will determine whether a funding instruction and SMS message should be sent. If so, the system will call the ledger to transfer funds and broadcast the SMS message. If not, the system will directly assemble the response message.
[0063] Optionally, after calling the second transaction interface of each tool, the method further includes: if calling the second transaction interface of each tool fails, cyclically calling the second transaction interface of each tool that failed to be called until the second transaction interfaces of all transaction tools are successfully called.
[0064] Optionally, Figure 15 The calling process of the second transaction interface is shown as follows: Figure 15 As shown, the system calls the second transaction interface of each transaction tool in sequence. If the call fails, the system calls in a loop until the second transaction interfaces of all transaction tools are successfully called.
[0065] Through the above steps, the two-stage transaction can be realized. The method embodiment of the present application can not only undertake more complex business scenarios, but also flexibly participate in the payment preparation and payment promotion stages, ensuring the ultimate consistency of the payment status between all payment tools participating in the payment promotion stage, effectively solving the risk of asset system loss, and effectively reducing the customer complaint rate.
[0066] The embodiment of the present application provides a transaction device, Figure 16 is a structural diagram of the device, such as Figure 16As shown, the device includes: an acquisition module 160, which is used to obtain the user's transaction request information, and call the first transaction interface of each transaction tool from the tool set according to the transaction request information, wherein the transaction request information includes the transaction tool information selected by the user, the virtual resource amount of the transaction, and the transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancellation. The first transaction interface is used to pre-occupy the virtual resource amount in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; a determination module 162, which is used to jointly determine the first transaction result according to the response results returned by each first transaction interface, wherein the first transaction result includes transaction success and transaction failure, and the response result includes response success and response failure; a calling module 164, which is used to determine the second transaction interface to be called according to the first transaction result, and call the second transaction interface of each tool to adjust the pre-occupied virtual resource amount, wherein the second transaction interface includes a transaction confirmation interface and a transaction cancellation interface, the transaction confirmation interface is used to execute the transaction strategy corresponding to the transaction type, and the transaction cancellation interface is used to roll back the transaction status.
[0067] In some embodiments of the present application, after the acquisition module 160 calls the first transaction interface corresponding to each transaction tool and transaction type from the tool set based on the transaction request information, the method also includes: obtaining preferential rule information, determining whether the transaction meets the preferential rules, and if the preferential rules are met, subtracting the preferential virtual resource amount from the virtual resource amount of the transaction, and updating the virtual resource amount corresponding to each transaction tool; and pre-occupying the virtual resource amount in each transaction tool based on the virtual resource amount corresponding to each transaction tool.
[0068] In some embodiments of the present application, before the determination module 162 jointly determines the first transaction result based on the response results returned by each first transaction interface, the method also includes: for each transaction tool, when the pre-occupation result is a successful pre-occupation, determining the response result as a successful response; for each transaction tool, when the pre-occupation result is a failed pre-occupation, determining the response result as a failed response; for each transaction tool, when the pre-occupation result is a response timeout, determining the response result as a failed response.
[0069] In some embodiments of the present application, the determination module 162 jointly determines the first transaction result based on the response results returned by each first transaction interface, including: when the response results of each transaction tool are all successful responses, determining the first transaction result as a successful transaction; when the response result of one transaction tool is a failed response, determining the first transaction result as a failed transaction.
[0070] In some embodiments of the present application, the calling module 164 determines the second transaction interface to be called based on the first transaction result, and calling the second transaction interface of each tool to adjust the reserved virtual resource amount includes: when the first transaction result is a successful transaction, calling the confirmation transaction interface of each transaction tool; when the first transaction result is a failed transaction, calling the cancellation transaction interface of each transaction tool.
[0071] In some embodiments of the present application, after the calling module 164 calls the cancel transaction interface of each trading tool, the method also includes: releasing the pre-occupation of the pre-occupied virtual resources in each trading tool; obtaining the call result returned by the cancel transaction interface, and displaying the transaction result to the user when the cancel transaction interface of each trading tool is successfully called.
[0072] In some embodiments of the present application, before the calling module 164 calls the transaction confirmation interface of each trading tool, the method also includes: obtaining preferential rule information to determine whether the transaction meets the preferential rules; if the preferential rules are met, subtracting the preferential virtual resource amount from the virtual resource amount of the transaction, and updating the virtual resource amount corresponding to each trading tool.
[0073] In some embodiments of the present application, after the calling module 164 calls the transaction confirmation interface of each transaction tool, the method further includes: when the coupon status is successfully updated, executing a corresponding transaction strategy on the pre-occupied virtual resource amount in each transaction tool according to the virtual resource amount corresponding to each transaction tool, and adjusting the status of the pre-occupied virtual resource amount; obtaining the call result returned by the transaction confirmation interface, and displaying the transaction result to the user when the transaction confirmation interface of each transaction tool is successfully called.
[0074] In some embodiments of the present application, after the calling module 164 calls the second transaction interface of each tool, the method also includes: in the event that the calling module 164 fails to call the second transaction interface of each tool, cyclically calling the second transaction interface of each tool that failed to be called until all transaction tools are successfully called.
[0075] It should be noted that the various modules in the above-mentioned transaction device can be program modules (for example, a set of program instructions that implement a certain specific function) or hardware modules. For the latter, it can be expressed in the following forms, but is not limited to this: the expression form of each of the above-mentioned modules is a processor, or the functions of each of the above-mentioned modules are implemented by a processor.
[0076] An embodiment of the present application provides a non-volatile storage medium, in which a program is stored, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the following transaction method: obtaining the user's transaction request information, and calling the first transaction interface of each transaction tool from the tool set according to the transaction request information, wherein the transaction request information includes the transaction tool information selected by the user, the virtual resource amount of the transaction, and the transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancellation, and the first transaction interface is used to pre-occupy the virtual resource amount in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; jointly determining the first transaction result based on the response results returned by each first transaction interface, wherein the first transaction result includes transaction success and transaction failure, and the response result includes response success and response failure; determining the second transaction interface to be called based on the first transaction result, and calling the second transaction interface of each tool to adjust the pre-occupied virtual resource amount, wherein the second transaction interface includes a transaction confirmation interface and a transaction cancellation interface, the transaction confirmation interface is used to execute the transaction strategy corresponding to the transaction type, and the transaction cancellation interface is used to roll back the transaction status.
[0077] An embodiment of the present application provides an electronic device, comprising: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes the following transaction method when running: obtaining transaction request information of a user, calling a first transaction interface of each transaction tool from a tool set based on the transaction request information, wherein the transaction request information includes transaction tool information selected by the user, a virtual resource amount of the transaction, and a transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancellation, the first transaction interface being configured to pre-occupy the virtual resource amount in each transaction tool, and the type of the first transaction interface corresponding to the transaction type of each transaction tool; jointly determining a first transaction result based on a response result returned by each first transaction interface, wherein the first transaction result includes a successful transaction and a failed transaction, and the response result includes a successful response and a failed response; determining a second transaction interface to be called based on the first transaction result, and calling the second transaction interface of each tool to adjust the pre-occupied virtual resource amount, wherein the second transaction interface includes a transaction confirmation interface and a transaction cancellation interface, wherein the transaction confirmation interface is configured to execute a transaction strategy corresponding to the transaction type, and the transaction cancellation interface is configured to roll back the transaction status.
[0078] An embodiment of the present application provides a computer program product, including a computer program, which implements the following transaction method when executed by a processor: obtaining user transaction request information, calling the first transaction interface of each transaction tool from a tool set based on the transaction request information, wherein the transaction request information includes the transaction tool information selected by the user, the virtual resource volume of the transaction, and the transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancellation, and the first transaction interface is used to pre-occupy the virtual resource volume in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; jointly determining the first transaction result based on the response results returned by each first transaction interface, wherein the first transaction result includes transaction success and transaction failure, and the response result includes response success and response failure; determining the second transaction interface to be called based on the first transaction result, and calling the second transaction interface of each tool to adjust the pre-occupied virtual resource volume, wherein the second transaction interface includes a transaction confirmation interface and a transaction cancellation interface, wherein the transaction confirmation interface is used to execute the transaction strategy corresponding to the transaction type, and the transaction cancellation interface is used to roll back the transaction status.
[0079] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.
[0080] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.
[0081] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.
[0082] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0083] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the relevant technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.
[0084] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.
Claims
1. A transaction method, characterized in that: include: Obtaining transaction request information from a user, and invoking a first transaction interface of each transaction tool from a tool set based on the transaction request information, wherein the transaction request information includes information about the transaction tool selected by the user, the amount of virtual resources to be traded, and a transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancel. The first transaction interface is used to pre-occupy the amount of virtual resources in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; Determining a first transaction result based on the response results returned by each of the first transaction interfaces, wherein the first transaction result includes transaction success and transaction failure, and the response result includes response success and response failure; Based on the first transaction result, determine the second transaction interface to be called, and call the second transaction interface of each tool to adjust the reserved virtual resource amount, wherein the second transaction interface includes a transaction confirmation interface and a transaction cancellation interface, the transaction confirmation interface is used to execute the transaction strategy corresponding to the transaction type, and the transaction cancellation interface is used to roll back the transaction status.
2. The transaction method according to claim 1, characterized in that: Invoking a first transaction interface corresponding to the transaction type for each transaction tool from a tool set according to the transaction request information, the method further includes: Obtain preferential rule information, determine whether the transaction meets the preferential rules, and if the preferential rules are met, subtract the preferential virtual resource amount from the virtual resource amount of the transaction, and update the virtual resource amount corresponding to each of the trading tools; Pre-occupying the virtual resources in each of the trading tools according to the virtual resources corresponding to each of the trading tools.
3. The transaction method according to claim 1, characterized in that: Before jointly determining the first transaction result based on the response results returned by each of the first transaction interfaces, the method further includes: For each transaction tool, if the pre-occupancy result is a pre-occupancy success, determining the response result as a response success; For each transaction tool, if the pre-occupancy result is pre-occupancy failure, determining the response result as response failure; For each transaction tool, when the pre-occupancy result is a response timeout, the response result is determined to be a response failure.
4. The transaction method according to claim 1, wherein: Determining the first transaction result based on the response results returned by each of the first transaction interfaces includes: When the response results of each of the transaction tools are all successful, determining the first transaction result as a successful transaction; In a case where the response result of the transaction tool is a response failure, the first transaction result is determined to be a transaction failure.
5. The transaction method according to claim 1, characterized in that: Determining a second transaction interface to be called based on the first transaction result, and calling the second transaction interface of each tool to adjust the reserved virtual resource amount includes: If the first transaction result is a successful transaction, calling the transaction confirmation interface of each of the transaction tools; When the first transaction result is a transaction failure, the transaction cancellation interface of each of the transaction tools is called.
6. The transaction method according to claim 5, characterized in that: After calling the transaction cancellation interface of each of the transaction tools, the method further includes: Release the pre-occupation of the virtual resources pre-occupied in each of the trading tools; Obtain the call result returned by the transaction cancellation interface, and display the transaction result to the user when the transaction cancellation interfaces of all the transaction tools are successfully called.
7. The transaction method according to claim 5, characterized in that: Before calling the transaction confirmation interface of each transaction tool, the method further includes: Obtain preferential rules information and determine whether the transaction meets the preferential rules; In the case where the preferential rules are met, the preferential virtual resource amount is subtracted from the transaction virtual resource amount, and the virtual resource amount and preferential usage status corresponding to each transaction tool are updated.
8. The transaction method according to claim 7, characterized in that: After calling the transaction confirmation interface of each of the transaction tools, the method further includes: When the preferential usage status is successfully updated, executing a corresponding trading strategy on the pre-occupied virtual resource amount in each trading tool according to the virtual resource amount corresponding to each trading tool, and adjusting the pre-occupied virtual resource amount status; Obtain the call result returned by the transaction confirmation interface, and display the transaction result to the user when the transaction confirmation interfaces of each of the transaction tools are successfully called.
9. The transaction method according to claim 1, characterized in that: After calling the second transaction interface of each of the tools, the method further includes: if calling the second transaction interface of each of the tools fails, cyclically calling the second transaction interface of each of the tools that failed to be called until the second transaction interfaces of all the transaction tools are successfully called.
10. A transaction device, characterized in that: include: an acquisition module, configured to acquire transaction request information from a user and, based on the transaction request information, invoke a first transaction interface for each transaction tool from a tool set, wherein the transaction request information includes information about the transaction tool selected by the user, the amount of virtual resources to be traded, and a transaction type, wherein the transaction type includes payment, refund, freeze, unfreeze, and cancel. The first transaction interface is configured to pre-occupy the amount of virtual resources in each transaction tool, and the type of the first transaction interface corresponds to the transaction type of each transaction tool; a determination module, configured to jointly determine a first transaction result based on the response results returned by each of the first transaction interfaces, wherein the first transaction result includes a transaction success or a transaction failure, and the response result includes a response success or a response failure; A calling module is used to determine the second transaction interface to be called based on the first transaction result, and call the second transaction interface of each tool to adjust the reserved virtual resource amount, wherein the second transaction interface includes a confirmation transaction interface and a cancellation transaction interface, the confirmation transaction interface is used to execute the transaction strategy corresponding to the transaction type, and the cancellation transaction interface is used to roll back the transaction status.
11. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a program, wherein when the program is executed, the device where the non-volatile storage medium is located is controlled to execute the transaction method according to any one of claims 1 to 9.
12. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the transaction method according to any one of claims 1 to 9 is executed when the program is run.
13. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the transaction method according to any one of claims 1 to 9 is implemented.