Order verification method, electronic equipment and storage medium

Abstract

The invention relates to an order verification method, electronic equipment and a storage medium, and the method comprises the steps: obtaining business data related to a transaction order in response to a creation instruction of the transaction order; executing a corresponding verification strategy on the transaction order according to the business data; and calling a corresponding financial software tool from the aggregated financial software toolkit to initiate a transaction according to the payment mode of the transaction order in response to passing of the verification. According to the technical scheme, the transaction order is verified according to the business data, and then the aggregation financial software toolkit is called to complete the transaction, so that the data accuracy and security in the transaction process can be ensured, and transaction failures caused by incompatibility of payment modes are reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an order verification method, electronic equipment and storage medium. Background Art

[0002] In existing payment services, when a payment request is passed from a gateway to a backend service, the backend service will call a specific financial software tool SDK (Software Development Kit) to complete the payment service. The inventor found the following problems in his research: In the payment processing process, the security verification related to the business data is insufficient or not comprehensive enough. Summary of the invention

[0003] In view of this, the purpose of this application is to provide an order verification method, electronic device and storage medium, which verify the transaction order according to the business data, and then call the aggregate financial software toolkit to complete the transaction, which can ensure the accuracy and security of the data during the transaction process and reduce transaction failures caused by incompatible payment methods.

[0004] To achieve the above purpose, the present application provides an order verification method, comprising:

[0005] In response to a creation instruction of a transaction order, acquiring business data related to the transaction order;

[0006] Execute a corresponding verification strategy on the transaction order according to the business data;

[0007] In response to the verification being passed, a corresponding financial software tool is called from the aggregate financial software toolkit according to the payment method of the transaction order to initiate a transaction.

[0008] In some embodiments, the transaction order includes a payment order, and executing a corresponding verification strategy on the transaction order according to the business data includes:

[0009] Querying the payment flow of the payment order in the business data;

[0010] If the business data contains a payment flow associated with the payment order, the payment order is further verified according to the payment status of the payment flow;

[0011] If there is no payment flow associated with the payment order in the business data, the verification is passed and a new payment flow is created to initiate payment for the payment order.

[0012] In some embodiments, the further verification of the payment order according to the payment status of the payment flow includes at least one of the following:

[0013] If the status of the payment flow is paid, the verification fails and the payment of the payment order is terminated;

[0014] If the status of the payment flow is "paying", a closing order is initiated. If the closing order is successful, the verification is passed; if the closing order fails, the verification fails;

[0015] If the status of the payment flow is non-existent, failed or invalid, the verification passes and a new payment flow is created to initiate payment for the payment order.

[0016] In some embodiments, the payment order includes a physical order and / or a service order, and the executing a corresponding verification strategy on the transaction order according to the business data includes at least one of the following:

[0017] If the payment order is a physical order, obtain a physical list associated with the payment order, verify at least one of the goods, price and inventory in the payment order according to the physical list, and perform payment verification according to the payment method of the payment order after the verification passes;

[0018] If the payment order is a service order, obtain a service list associated with the payment order, verify at least one of the service item, service amount and service time of the payment order according to the service list, and perform payment verification according to the online payment result of the payment order after the verification passes;

[0019] If the payment order is a mixed order of a physical order and a service order, the payment order is split into the physical order and the service order and then verified separately.

[0020] In some embodiments, the payment method includes cash payment, online payment and / or credit payment, and the payment verification includes at least one of the following:

[0021] If the payment method is online payment, the cumulative payment amount and the order amount are verified. The verification is passed when the cumulative payment amount reaches the order amount;

[0022] If the payment method is cash payment, a cash entry form is created, and the cash entry form and the order amount are verified to be matched.

[0023] If the payment method is payment on credit, the verification is passed when the total amount of the repayment plan matches the order amount, and the number of planned periods and repayment time are within the preset range.

[0024] In some embodiments, the transaction order includes a refund order, and executing a corresponding verification strategy on the transaction order according to the business data includes:

[0025] Query the payment flow and refund record of the refund order in the business data;

[0026] The refund order is verified according to the payment flow and / or refund record.

[0027] In some embodiments, the verifying the refund order according to the payment flow and / or refund record includes at least one of the following:

[0028] If there is a refund record associated with the refund order and the refund is successful, the verification fails and the refund transaction is not allowed to be initiated;

[0029] If the refund record shows that the refund is not completed, and the payment flow shows a non-successful status, the verification fails and the refund transaction is not allowed to be initiated;

[0030] If the refund amount of the refund order is greater than the payment amount, the verification fails and the refund transaction is not allowed to be initiated.

[0031] In some embodiments, the refund order includes a physical order and a service order, and the executing a corresponding verification strategy on the transaction order according to the business data includes at least one of the following:

[0032] If the refund order is a physical order, then verify the refund amount and physical return status of the refund order;

[0033] If the refund order is a service order, verify the service completion status corresponding to the refund order;

[0034] If the refund order is a mixed order of a physical order and a service order, the refund order is split into the physical order and the service order and then verified separately.

[0035] The present application also provides an electronic device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of any of the above methods when executed by the processor.

[0036] The present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0037] From the above, the order verification method, electronic device and storage medium of the present application include: in response to the creation instruction of the transaction order, obtaining the business data related to the transaction order; executing the corresponding verification strategy on the transaction order according to the business data; in response to the verification passing, calling the corresponding financial software tool from the aggregate financial software toolkit according to the payment method of the transaction order to initiate the transaction. The technical solution of the present application verifies the transaction order according to the business data, and then calls the aggregate financial software toolkit to complete the transaction, which can ensure the accuracy and security of the data in the transaction process and reduce the transaction failure caused by incompatible payment methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0039] Figure 1 The present invention is a flowchart of an order verification method provided according to an embodiment.

[0040] Figure 2 A system architecture diagram for executing an order verification method provided according to an embodiment.

[0041] Figure 3 The present invention is a schematic diagram of a specific process of an order verification method provided according to an embodiment.

[0042] Figure 4 The figure is a schematic diagram of the structure of an electronic device provided according to an embodiment. DETAILED DESCRIPTION

[0043] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0044] It should be noted that, in this article, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element. In addition, components, features, and elements with the same name in different embodiments of the present application may have the same meaning or different meanings, and their specific meanings need to be determined by their explanation in the specific embodiment or further combined with the context of the specific embodiment.

[0045] It should be understood that, although the terms first, second, third, etc. may be used to describe various information in this article, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this article, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "at the time of..." or "when..." or "in response to determination". Furthermore, as used in this article, the singular forms "one", "one" and "the" are intended to also include plural forms, unless there is an opposite indication in the context. It should be further understood that the terms "comprising", "including" indicate that there are described features, steps, operations, elements, components, projects, kinds, and / or groups, but do not exclude the existence, occurrence or addition of one or more other features, steps, operations, elements, components, projects, kinds, and / or groups. The terms "or" and "and / or" used herein are interpreted as inclusive, or mean any one or any combination. Thus, “A, B, or C” or “A, B and / or C” means “any of the following: A; B; C; A and B; A and C; B and C; A, B, and C.” An exception to this definition will occur only when a combination of elements, functions, steps, or operations are inherently mutually exclusive in some manner.

[0046] It should be understood that, although the various steps in the flowchart in the embodiment of the present application are displayed in sequence according to the indication of the arrows, these steps are not necessarily performed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and it can be performed in other orders. Moreover, at least a portion of the steps in the figure may include a plurality of sub-steps or a plurality of stages, and these sub-steps or stages are not necessarily performed at the same time, but can be performed at different times, and their execution order is not necessarily performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0047] It should be noted that in this article, step codes such as S1 and S2 are used for the purpose of expressing the corresponding content more clearly and concisely, and do not constitute a substantial limitation on the order. When implementing the step, those skilled in the art may execute S2 first and then S1, etc., but these should all be within the scope of protection of this application.

[0048] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0049] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application, and have no specific meanings. Therefore, "module", "component" or "unit" can be used in a mixed manner.

[0050] The following is an explanation of the terms that may be involved in this application, as follows:

[0051] SDK: SDK is a software development kit provided by the service provider. As payment service providers, WeChat, Alipay and other vendors provide online payment services through payment SDK. These payment SDKs ensure the security of payment data through encryption methods such as security certificates.

[0052] However, these payment SDKs are decoupled from business logic. They only provide the ability to safely transfer funds and do not focus on business data.

[0053] In order to solve the problems of the prior art, the present invention provides a Figure 1 The following is a flow chart of an order verification method according to an embodiment. The order verification method can be implemented in software and / or hardware. In this embodiment, the execution subject of the order verification method is a computer device as an example.

[0054] like Figure 2 As shown, the order verification method of the embodiment of the present application includes the following steps:

[0055] S1, in response to a transaction order creation instruction, obtaining business data related to the transaction order.

[0056] In this embodiment, a transaction order is a commercial transaction document used to confirm transaction details and serve as a basis for subsequent processing (such as delivery, payment, refund, etc.). Transaction orders include payment orders and refund orders. A payment order is an order generated during the transaction process that records the buyer's payment behavior. A refund order is an order generated when the buyer applies for a partial or full refund of the payment due to some reasons (such as product quality issues, buyer canceling the order, etc.) after the payment order is completed and the transaction is completed.

[0057] After creating a transaction order, obtain business data related to the transaction order from the business database, and use the business data to verify the transaction order to improve data accuracy and security during the transaction process.

[0058] S2, execute corresponding verification strategy on transaction orders according to business data.

[0059] In this embodiment, the business data related to the transaction order is used to execute the predetermined verification rules to ensure the validity and rationality of the transaction order. Among them, the verification strategy includes but is not limited to integrity verification, consistency verification, logic verification, security verification and compliance verification. Among them, the integrity verification can be to check whether the buyer's name, contact information and address are complete; check whether the product name, specifications, quantity, unit price and total price are complete; and check whether the payment method and payment status are clear. The consistency verification can be to check whether the unit price of the product is consistent with the standard price; check whether the inventory is sufficient to meet the order requirements; and check whether the total order amount is equal to the total price of the product plus the freight. The logic verification can be to check whether the number of products in the order is reasonable (for example, it cannot be negative or exceed the inventory limit); check whether the payment amount is consistent with the total order amount; and check whether the refund amount does not exceed the payment amount. The security verification can be to check whether there is repeated payment behavior; check the security of the payment method, such as verifying the security of the payment platform when paying online; and check the buyer's identity information to ensure that the transaction is initiated by a legitimate user. Compliance verification can be to check whether the order complies with the requirements of relevant laws and regulations, such as tax regulations; check whether the refund policy complies with company and legal regulations.

[0060] S3, in response to the verification being passed, calling the corresponding financial software tool from the aggregate financial software toolkit according to the payment method of the transaction order to initiate the transaction.

[0061] In this embodiment, the aggregate financial software toolkit is a software solution that integrates multiple payment service provider interfaces. It provides merchants with a unified interface to access different payment services, simplifying the process of integrating multiple payment options. The aggregate financial software toolkit may contain all APIs and service endpoints required for different payment methods, as well as necessary security measures and protocol support (such as SSL / TLS encryption). When the specific payment method of the transaction order is identified, the corresponding financial software tool in the aggregate financial software toolkit will be automatically selected and called to obtain payment services. In this way, the workload of payment integration is simplified, allowing merchants to easily support multiple payment methods, while also improving the security of the payment process and user experience.

[0062] In some embodiments, Figure 2 As shown, in the system architecture for executing the order verification method, the service gateway is used to receive the application program interface call from the client and distribute the request to the backend service. The backend service processes the request from the service gateway, executes the business logic, such as processing the creation and verification of the transaction order, and returns the corresponding result. The SDK front-end module receives the data transmitted by the backend service and is responsible for connecting to different SDKs. Its functions include but are not limited to order duplicate payment verification, payment refund association verification and amount rationality verification. It can also customize the verification rules in the custom verification submodule according to actual needs, so as to provide an extension method to flexibly adjust the business verification logic and improve the coding freedom. The aggregation SDK module is a specific example of an aggregation financial software toolkit, which integrates multiple different SDKs and provides a unified interface for the backend service, which helps to simplify the development work and reduce the direct interaction with different payment service providers. The aggregation SDK module includes SDK 1 submodule, SDK 2 submodule and SDK 3 submodule, etc. These submodules are software development kits provided by different payment service providers for integrating their payment services. The business database is used to store business data related to transaction orders, such as buyer information, seller information, product information, payment information, delivery information and other information.

[0063] When the client initiates a request to create a transaction order, the request first reaches the service gateway. The service gateway forwards the request to the backend service. The backend service obtains business data from the business database based on the request content, and then verifies the transaction order through the SDK front-end module. If the verification is successful, the backend service uses the aggregated SDK module to send the request to the corresponding SDK (which may be SDK 1, SDK 2, or SDK 3). The corresponding SDK processes the request and returns the result to the backend service. Finally, the backend service returns the processing result to the service gateway, and the service gateway sends the result back to the client. In this way, the security and reliability of the creation and payment process of the transaction order can be ensured. In addition, in this way, multiple payment methods can be effectively processed, and new payment service providers can be flexibly expanded according to needs.

[0064] In some embodiments, the transaction order includes a payment order, and a corresponding verification strategy is executed on the transaction order according to the business data, including:

[0065] Query the payment flow of the payment order in the business data;

[0066] If there is a payment slip associated with the payment order in the business data, the payment order will continue to be verified based on the payment status of the payment slip;

[0067] If there is no payment flow associated with the payment order in the business data, the verification passes and a new payment flow is created to initiate payment for the payment order.

[0068] In some embodiments, the payment order is further verified according to the payment status of the payment flow, including at least one of the following:

[0069] If the payment transaction status is paid, the verification fails and the payment order is terminated;

[0070] If the payment flow status is in payment, the order closing is initiated. If the order closing is successful, the verification is passed. If the order closing fails, the verification fails.

[0071] If the status of the payment slip is non-existent, failed or invalid, the verification passes and a new payment slip is created to initiate payment for the payment order.

[0072] As an implementation method of this embodiment, please refer to Figure 3, when the user initiates a payment, a payment order is generated. Query the payment flow of the payment order in the business database to determine whether there is a payment flow associated with the payment order in the business database. If there is no payment flow, the verification is passed, and a new payment flow can be created to initiate payment for the payment order. If there is a payment flow, continue to query the payment status of the payment flow. If the payment status is paid, the payment process ends, the verification fails, and there is no need to continue to create a payment flow. If the payment status is non-existent, failed, or invalidated, a new payment flow is created and payment is initiated. That is, if no valid payment flow is found or the payment status is abnormal, a new payment flow is created and a new payment is attempted. If the payment is successful, the payment process ends. If the payment fails, initiate a closure, that is, cancel the unfinished payment. Wait for the closure result to be returned. If the closure is successful and the verification is passed, a new payment flow can be created to initiate payment for the payment order; if the closure fails and the verification fails, there is no need to continue to create a payment flow.

[0073] In this way, the accuracy and consistency of the payment process are ensured through detailed payment flow query and payment status verification. This not only improves the user experience, but also optimizes resource utilization, enhances security, and supports flexible payment strategies that are efficient, reliable, and easy to manage.

[0074] In some embodiments, the payment order includes a physical order and / or a service order, and a corresponding verification strategy is executed on the transaction order according to the business data, including at least one of the following:

[0075] If the payment order is a physical order, obtain the physical list associated with the payment order, verify at least one of the goods, price and inventory in the payment order according to the physical list, and perform payment verification according to the payment method of the payment order after the verification passes;

[0076] If the payment order is a service order, obtain a service list associated with the payment order, verify at least one of the service item, service amount, and service time of the payment order according to the service list, and perform payment verification according to the online payment result of the payment order after the verification passes;

[0077] If the payment order is a mixed order of physical order and service order, the payment order will be split into physical order and service order and then verified separately.

[0078] It should be noted that payment orders can be physical orders, service orders, or a combination of the two. Physical orders refer to orders for specific tangible goods purchased by users, which generally involve factors such as product quality, inventory management, and logistics transportation. These goods are usually items that can be delivered to customers physically, such as electronic products, clothing, food, books, etc. Service orders refer to orders for service items purchased by users, which generally involve factors such as service quality, service progress, and service content adjustments. These service items are intangible and cannot be delivered physically, but can meet customer needs by providing specific services. For example, consulting services, maintenance services, education and training, software subscriptions, etc.

[0079] As an implementation method of this embodiment, if the payment order is a physical order, a physical list associated with the payment order is extracted from the business database, which contains relevant product information. The verification process of the payment order based on the physical list includes but is not limited to checking whether the goods in the list exist in the current inventory, whether the quantity is sufficient to meet the order requirements, and whether the detailed description of the goods (such as price, specifications, model, etc.) is accurate. After this verification is passed, further verification will be performed based on the payment method selected by the user. For example, online payment requires verification of the user's payment information, cash payment requires creation of a cash entry form and amount matching, and payment on credit requires review of credit status and collection plan, etc.

[0080] As an implementation method of this embodiment, if the payment order is a service order, the service list associated with the payment order is extracted to list all service items and their details. The process of verifying the payment order according to the service list includes but is not limited to verifying whether the items in the service list are legitimate services provided by the company; whether it is capable of providing these services within the specified time; whether the amount in the service list is reasonable, including the total price and the cost of each individual service; verifying whether the time arrangement for the provision of the service is logical, such as whether it is within working hours, whether it conflicts with other scheduled services, etc. Service orders are generally paid online. If the payment is successful, the order will continue to be processed; if the payment fails, the order will be cancelled or wait for re-payment.

[0081] As an implementation method of this embodiment, if the order is a mixture of a physical order and a service order, each part will be processed according to its corresponding verification rules. That is, the physical order part is executed according to the verification process of the physical order, and the service order part follows the verification process of the service order. When both parts pass their respective verifications, the entire mixed order will be considered valid. If any part fails to pass the verification, the user can be notified to modify the order or cancel the order.

[0082] In this way, the accuracy and efficiency of order processing are improved through a multi-level verification mechanism. For different order types (physical orders, service orders, mixed orders), corresponding records can be created adaptively and corresponding verification rules can be applied to ensure data consistency and accuracy.

[0083] In some embodiments, the payment method includes cash payment, online payment and / or credit payment, and the payment verification includes at least one of the following:

[0084] If the payment method is online payment, the cumulative payment amount and the order amount are verified. The verification is passed when the cumulative payment amount reaches the order amount;

[0085] If the payment method is cash payment, a cash entry form is created. The verification passes when the cash entry form and the order amount match;

[0086] If the payment method is credit payment, the verification passes when the total amount of the repayment plan matches the order amount, and the planned number of periods and repayment time are within the preset range.

[0087] As an implementation method of this embodiment, when the payment order processed is a physical order, a payment order, a payment collection plan and a physical list will be created. Supported payment methods include online payment, cash payment and credit payment. After creating these records, check whether the physical list associated with the order is complete.

[0088] If the payment method is online payment, the progress of the payment plan is updated according to the cumulative amount paid by the user. When the cumulative payment amount is equal to or exceeds the total order amount, the payment plan is marked as completed.

[0089] If the payment method is cash payment, in addition to creating a payment order, a cash entry slip is also generated. When the amount on the cash entry slip matches the order amount, the payment is confirmed to be successful, and the payment order and collection plan are completed.

[0090] If the payment method is credit payment, check whether the total amount in the payment plan is consistent with the order amount, and check whether the number of planned periods and the repayment time of each period are reasonable. When checking whether the number of planned periods and repayment time are within the preset range, judgment can be made based on one or more of the debt-to-income ratio, the monthly repayment amount as a percentage of income, the total interest expenditure, the loan term, and the minimum monthly repayment amount. For example, the debt-to-income ratio does not exceed 36%, the monthly repayment amount as a percentage of income does not exceed 40%, the total interest expenditure does not exceed 20% of the loan principal, the loan term does not exceed 5 years (60 months), and the minimum monthly repayment amount is not less than a certain amount (for example, not less than 1,000 yuan). If the total amount of the payment plan matches the order amount, and the number of planned periods and repayment time are within the preset range, credit payment is allowed.

[0091] In this way, by supporting multiple payment methods (online payment, cash payment, and payment on credit), the needs of different customers are met and the flexibility of the business is increased.

[0092] In some embodiments, the transaction order includes a refund order, and a corresponding verification strategy is executed on the transaction order according to the business data, including:

[0093] Query the payment flow and refund records of the refund order in the business data;

[0094] Verify the refund order based on the payment flow and / or refund record.

[0095] In some embodiments, verifying the refund order according to the payment flow and / or the refund record includes at least one of the following:

[0096] If there is a refund record associated with the refund order and the refund is successful, the verification fails and the refund transaction is not allowed to be initiated;

[0097] If the refund record shows that the refund is not completed and the payment flow shows a non-successful status, the verification fails and the refund transaction is not allowed to be initiated;

[0098] If the refund amount of the refund order is greater than the payment amount, the verification fails and the refund transaction is not allowed to be initiated.

[0099] As an implementation method of this embodiment, firstly, the payment flow record associated with the refund order is queried from the business database. The payment flow records all payment related information of the order, such as the payment amount, payment time, payment status, etc. At the same time, the refund record associated with the refund order is queried. The refund record contains information such as the time of the refund request, the refund amount, and the refund status. In order to ensure the validity and accuracy of the refund operation, the corresponding verification strategy is executed on the refund order according to the payment flow and / or refund record in the business data.

[0100] If there is already a refund record associated with the refund order, and the refund status is displayed as "successful", the verification fails and a new refund transaction is not allowed. This can avoid duplicate refunds and prevent capital losses.

[0101] If the refund record shows that the refund is not completed (for example, the refund status is "pending", "failed", etc.), and the payment flow shows that the payment status is not successful (for example, "failed", "cancelled", etc.), the verification fails and the refund transaction is not allowed. In this case, you may need to further investigate the reason for the payment failure, or wait for the payment status to be updated before processing.

[0102] If the refund amount in the refund order is greater than the payment amount of the original payment order, the verification fails and the refund transaction is not allowed. This verification can prevent over-refunds and ensure that the refund amount does not exceed the actual payment amount.

[0103] In this way, the accuracy and efficiency of refund processing are improved through a multi-level verification mechanism.

[0104] In some embodiments, the refund order includes a physical order and a service order, and a corresponding verification strategy is executed on the transaction order according to the business data, including at least one of the following:

[0105] If the refund order is a physical order, verify the refund amount and physical return status of the refund order;

[0106] If the refund order is a service order, verify the service completion status corresponding to the refund order;

[0107] If the refund order is a mixed order of physical orders and service orders, the refund order will be split into physical orders and service orders and then verified separately.

[0108] As an implementation method of this embodiment, when the refund order is a physical order and the payment method is online payment, a refund operation is allowed. Before executing the refund, the verification content includes but is not limited to: confirming that the refund amount does not exceed the original order amount; checking the return status of the goods in the physical list to ensure that all goods that need to be refunded have been returned or are in a returnable state.

[0109] If the payment method is cash payment, the verification content includes but is not limited to: confirming that the amount on the cash entry form is consistent with the order amount; checking the status of the cash entry form to ensure that it is in a refundable state. In addition, whether the payment method is online payment or cash payment, online refund operations are supported to improve the user experience.

[0110] When the refund order is a service order, the completion status of the service order will be verified before the refund operation is executed. The verification content includes but is not limited to: if the service order has been completed (that is, the service has been provided), the refund operation is not allowed; if the service order has not been completed, whether to allow the refund will be determined based on the specific circumstances, and the user may be required to provide relevant supporting documents.

[0111] When the refund order is a mixed order containing physical goods and service items, the refund order will be decomposed and the verification logic of related types of orders will be reused respectively.

[0112] From the above, the order verification method of the embodiment of the present application, in response to the creation instruction of the transaction order, obtains the business data related to the transaction order; executes the corresponding verification strategy on the transaction order according to the business data; in response to the verification passing, calls the corresponding financial software tool from the aggregate financial software toolkit according to the payment method of the transaction order to initiate the transaction. The technical solution of the present application verifies the transaction order according to the business data, and then calls the aggregate financial software toolkit to complete the transaction, which can ensure the accuracy and security of the data in the transaction process and reduce the transaction failure caused by incompatible payment methods.

[0113] Based on the same inventive concept as the above embodiments, an embodiment of the present invention provides an electronic device, such as Figure 4 As shown, the electronic device includes: a processor 310 and a memory 311 storing a computer program; wherein, Figure 4 The processor 310 shown in the figure is not used to indicate that the number of the processor 310 is one, but is only used to indicate the positional relationship of the processor 310 relative to other devices. In actual applications, the number of the processor 310 may be one or more; similarly, Figure 4 The memory 311 shown in the figure has the same meaning, that is, it is only used to refer to the position relationship of the memory 311 relative to other devices. In practical applications, the number of memories 311 can be one or more. When the processor 310 runs the computer program, the method applied to the above device is implemented.

[0114] The electronic device may also include: at least one network interface 312. The various components in the electronic device are coupled together via a bus system 313. It is understood that the bus system 313 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 313 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 313 is not used in the following examples. Figure 4 Various buses are labeled as bus system 313.

[0115] The memory 311 may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories. The nonvolatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM); the magnetic surface memory may be a disk memory or a tape memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM, SyncLink Dynamic Random Access Memory), and direct RAM bus random access memory (DRRAM, Direct Rambus Random Access Memory).The memory 311 described in the embodiments of the present invention is intended to include but is not limited to these and any other suitable types of memories.

[0116] The memory 311 in the embodiment of the present invention is used to store various types of data to support the operation of the electronic device. Examples of these data include: any computer program used to operate on the electronic device, such as an operating system and an application; contact data; phone book data; messages; pictures; videos, etc. Among them, the operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks. The application program may include various applications, such as a media player (Media Player), a browser (Browser), etc., which are used to implement various application services. Here, the program that implements the method of the embodiment of the present invention may be included in the application program.

[0117] Based on the same inventive concept as the above-mentioned embodiment, this embodiment further provides a computer-readable storage medium, in which a computer program is stored. The computer-readable storage medium may be a ferromagnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); it may also be various devices including one or any combination of the above memories, such as a mobile phone, a computer, a tablet device, a personal digital assistant, etc. When the computer program stored in the computer-readable storage medium is executed by the processor, the above method is implemented. For the specific steps implemented when the computer program is executed by the processor, please refer to Figure 1 The description of the illustrated embodiment will not be repeated here.

[0118] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described 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.

[0119] In this document, the terms "comprises," "comprising," or any other variations thereof, are intended to cover a non-exclusive inclusion of elements other than those listed and may also include additional elements not expressly listed.

[0120] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. An order verification method, characterized in that: include: In response to a creation instruction of a transaction order, acquiring business data related to the transaction order; Execute a corresponding verification strategy on the transaction order according to the business data; In response to the verification being passed, a corresponding financial software tool is called from the aggregate financial software toolkit according to the payment method of the transaction order to initiate a transaction.

2. The method according to claim 1, characterized in that: The transaction order includes a payment order, and the executing a corresponding verification strategy on the transaction order according to the business data includes: Querying the payment flow of the payment order in the business data; If the business data contains a payment flow associated with the payment order, the payment order is further verified according to the payment status of the payment flow; If there is no payment flow associated with the payment order in the business data, the verification is passed and a new payment flow is created to initiate payment for the payment order.

3. The method according to claim 2, characterized in that The further verifying the payment order according to the payment status of the payment flow includes at least one of the following: If the status of the payment flow is paid, the verification fails and the payment of the payment order is terminated; If the status of the payment flow is "paying", a closing order is initiated. If the closing order is successful, the verification is passed; if the closing order fails, the verification fails; If the status of the payment flow is non-existent, failed or invalid, the verification passes and a new payment flow is created to initiate payment for the payment order.

4. The method according to claim 2, characterized in that: The payment order includes a physical order and / or a service order, and the executing a corresponding verification strategy on the transaction order according to the business data includes at least one of the following: If the payment order is a physical order, obtain a physical list associated with the payment order, verify at least one of the goods, price and inventory in the payment order according to the physical list, and perform payment verification according to the payment method of the payment order after the verification passes; If the payment order is a service order, obtain a service list associated with the payment order, verify at least one of the service item, service amount and service time of the payment order according to the service list, and perform payment verification according to the online payment result of the payment order after the verification passes; If the payment order is a mixed order of a physical order and a service order, the payment order is split into the physical order and the service order and then verified separately.

5. The method according to claim 4, characterized in that The payment method includes cash payment, online payment and / or credit payment, and the payment verification includes at least one of the following: If the payment method is online payment, the cumulative payment amount and the order amount are verified. The verification is passed when the cumulative payment amount reaches the order amount; If the payment method is cash payment, a cash entry form is created, and the cash entry form and the order amount are verified to be matched. If the payment method is credit payment, the verification is passed when the total amount of the repayment plan matches the order amount, and the number of planned periods and repayment time are within the preset range.

6. The method according to claim 1, characterized in that The transaction order includes a refund order, and the executing a corresponding verification strategy on the transaction order according to the business data includes: Query the payment flow and refund record of the refund order in the business data; The refund order is verified according to the payment flow and / or refund record.

7. The method according to claim 6, characterized in that Verifying the refund order according to the payment flow and / or refund record includes at least one of the following: If there is a refund record associated with the refund order and the refund is successful, the verification fails and the refund transaction is not allowed to be initiated; If the refund record shows that the refund is not completed, and the payment flow shows a non-successful status, the verification fails and the refund transaction is not allowed to be initiated; If the refund amount of the refund order is greater than the payment amount, the verification fails and the refund transaction is not allowed to be initiated.

8. The method according to claim 1, characterized in that The refund order includes a physical order and a service order, and the corresponding verification strategy is executed on the transaction order according to the business data, including at least one of the following: If the refund order is a physical order, then verify the refund amount and physical return status of the refund order; If the refund order is a service order, verify the service completion status corresponding to the refund order; If the refund order is a mixed order of a physical order and a service order, the refund order is split into the physical order and the service order and then verified separately.

9. An electronic device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the method according to any one of claims 1 to 8 when executed by the processor.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images