Payment transaction method, device and equipment and readable storage medium

Abstract

The invention provides a payment transaction method, apparatus and device, and a readable storage medium, and the method comprises the steps: receiving the instruction information included in a transaction instruction sent by a server after the transaction instruction is generated at the server, verifying the instruction information of the transaction instruction according to the first business information corresponding to a business request initiated by a client, and sending the verification result to the server; according to the technical scheme, the server processes the transaction instruction according to the verification result, so that error information in the transaction instruction can be found in time, transaction failure or abnormal conditions caused by transaction instruction errors are reduced, fund safety of a user and transaction interests are ensured not to be lost, trust and satisfaction of the user are enhanced, and transaction efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a payment transaction method, apparatus, device, and readable storage medium. Background Art

[0002] With the emergence of emerging payment methods such as mobile payment and digital currency, payment transactions have become an indispensable part of daily life and commercial activities.

[0003] During the payment transaction process, in scenarios such as user foreign exchange settlement and salary payment, refund, and fund withdrawal, when a user initiates a service request on the client side, the service request will be sent to the server side; the payment system of the server side generates a transaction instruction according to the service request, such as a payment instruction, a refund execution, and issues the transaction instruction to a bank or a payment institution for fund transfer processing.

[0004] However, during the process of generating a transaction instruction according to a service request, due to possible data synchronization errors, network communication failures, program logic errors, etc., the information included in the generated transaction instruction is inconsistent with the information of the transaction service requested by the user, resulting in payment transaction errors and affecting the user experience. Summary of the Invention

[0005] In view of this, to solve the above technical problems, this application provides a payment transaction method, apparatus, device, and readable storage medium.

[0006] Specifically, this application is implemented through the following technical solutions:

[0007] According to the first aspect of the embodiments of this application, a payment transaction method is provided, and the method includes:

[0008] Receiving first service information generated when a client initiates a service request;

[0009] Receiving instruction information included in a transaction instruction generated by a server according to the service request; the instruction information includes second service information and an instruction identifier; the second service information and the first service information include the same type of parameters;

[0010] Verifying the second service information according to the first service information to generate a verification result;

[0011] Sending the instruction identifier and the verification result to the server, so that the server processes the transaction instruction indicated by the instruction identifier according to the verification result.

[0012] Optionally, after receiving the first service information, the method includes: storing the first service information in a local list; when the local list stores the first service information corresponding to at least two service requests, the verifying the second service information according to the first service information includes:

[0013] Verifying the second service information according to each piece of first service information in turn according to the storage time of each group of first service information in the local list;

[0014] In response to the verification result indicating successful verification, removing the first service information used at the time of successful verification from the local list.

[0015] Optionally, the same type of parameters includes at least a service request identifier, and at least one of a service type and a transaction amount; the verifying the second service information to generate a verification result includes:

[0016] Comparing the service request identifiers in the first service information and the second service information;

[0017] In response to the service request identifiers being different, generating a first verification result indicating verification failure;

[0018] In response to the service request identifiers being the same, comparing the same type of parameters in the first service information and the second service information except the service request identifier in turn;

[0019] When the values of the same type of parameters are all the same, generating a second verification result indicating successful verification.

[0020] Optionally, the verifying the second service information to generate a verification result includes:

[0021] Generating a first hash value corresponding to the same type of parameters in the first service information and a second hash value corresponding to the same type of parameters in the second service information according to a preset hash algorithm;

[0022] In response to the first hash value being different from the second hash value, generating a first verification result indicating verification failure;

[0023] In response to the first hash value being the same as the second hash value, generating a second verification result indicating successful verification.

[0024] Optionally, before verifying the second service information, the method further includes:

[0025] Check whether the instruction identifier list stored locally includes the instruction identifier in the instruction information; the instruction identifier list is used to store the instruction identifiers of the transaction instructions that have been verified.

[0026] If so, generate a third verification result indicating repeated verification and send it to the server.

[0027] If not, perform verification processing on the second service information.

[0028] Optionally, the method further includes:

[0029] In the case where the verification result indicates verification failure, send the verification result to the client so that the client can resend the service request in a set manner.

[0030] According to the second aspect of the embodiments of the present application, a payment transaction device is provided, and the device includes:

[0031] A first service information acquisition module, configured to receive the first service information generated when the client initiates a service request.

[0032] An instruction information acquisition module, configured to receive the instruction information included in the transaction instruction generated by the server according to the service request; the instruction information includes second service information and an instruction identifier; the second service information and the first service information include parameters of the same type.

[0033] A second service information verification module, configured to verify the second service information according to the first service information and generate a verification result.

[0034] A transaction instruction processing module, configured to send the instruction identifier and the verification result to the server so that the server processes the transaction instruction indicated by the instruction identifier according to the verification result.

[0035] Optionally, after receiving the first service information, the device includes: storing the first service information in a local list.

[0036] When the local list stores the first service information corresponding to at least two service requests, the second service information verification module is specifically configured to:

[0037] Verify the second service information according to each piece of first service information in turn according to the storage time of each piece of first service information in the local list.

[0038] In response to the verification result indicating verification success, remove the first service information used when the verification is successful from the local list.

[0039] Optionally, the same type of parameters at least includes a service request identifier, and at least includes at least one of a service type and a transaction amount; the second service information verification module is specifically configured to:

[0040] Compare the service request identifiers in the first service information and the second service information;

[0041] In response to the service request identifiers being different, generate a first verification result indicating verification failure;

[0042] In response to the service request identifiers being the same, sequentially compare the same type of parameters in the first service information and the second service information except the service request identifier;

[0043] In the case where the values of the same type of parameters are all the same, generate a second verification result indicating verification success.

[0044] Optionally, the second service information verification module is specifically configured to:

[0045] According to a preset hash algorithm, generate a first hash value corresponding to the same type of parameters in the first service information and a second hash value corresponding to the same type of parameters in the second service information;

[0046] In response to the first hash value being different from the second hash value, generate a first verification result indicating verification failure;

[0047] In response to the first hash value being the same as the second hash value, generate a second verification result indicating verification success.

[0048] Optionally, before verifying the second service information, the device further includes:

[0049] Detect whether the instruction identifier in the instruction information is included in the local instruction identifier list; the instruction identifier list is used to store the instruction identifiers of the transaction instructions that have been verified;

[0050] If so, generate a third verification result indicating repeated verification and send it to the server;

[0051] If not, perform verification processing on the second service information.

[0052] Optionally, the device may further include:

[0053] In the case where the verification result indicates verification failure, send the verification result to the client so that the client re-initiates the service request in a set manner.

[0054] According to a third aspect of the embodiments of the present application, an electronic device is provided, and the electronic device includes: a memory and a processor; the memory is used to store a computer program; the processor is used to execute the above payment transaction method by calling the computer program.

[0055] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the above payment transaction method is implemented.

[0056] The technical solutions provided by the embodiments of the present application may include the following beneficial effects:

[0057] In the technical solution provided by the present application above, after a transaction instruction is generated on the server side, the instruction information included in the transaction instruction sent by the server side is received, and the instruction information of the transaction instruction is verified according to the first service information corresponding to the service request initiated by the client, so that the server side processes the transaction instruction according to the verification result, thereby being able to timely discover the error information in the transaction instruction, reducing the transaction failure or abnormal situation caused by the error of the transaction instruction, ensuring the safety of the user's funds and the transaction interests are not damaged, enhancing the user's trust and satisfaction, and improving the transaction efficiency.

[0058] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. In addition, any embodiment in the present application does not need to achieve all the above effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] The drawings here are incorporated into the specification and form a part of the specification, showing the embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0060] Figure 1 is an interaction diagram of a server side and a client side for completing a payment transaction in response to a user's service request in the related art shown exemplarily;

[0061] Figure 2 is a schematic flowchart of a payment transaction method shown in an exemplary embodiment of the present application;

[0062] Figure 3 is a flowchart of verifying second service information in the case of receiving multiple first service information shown in an exemplary embodiment of the present application;

[0063] Figure 4 is a flowchart of verifying second service information according to first service information shown in an exemplary embodiment of the present application;

[0064] Figure 5Another flowchart for verifying the second service information based on the first service information shown in an exemplary embodiment of the present application;

[0065] Figure 6 A method flowchart for detecting duplicate verification of service information based on the instruction identifier of a transaction instruction shown in an exemplary embodiment of the present application;

[0066] Figure 7 A schematic diagram of the interaction between the server and the client in a payment transaction method shown in an exemplary embodiment of the present application;

[0067] Figure 8 A schematic structural diagram of a payment transaction device shown in an exemplary embodiment of the present application;

[0068] Figure 9 A schematic diagram of the hardware of an electronic device shown in an exemplary embodiment of the present application. Detailed implementation manners

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

[0070] The terms used in the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. The singular forms "a", "the", and "said" used in the present application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0071] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, 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 the present application, the first classification threshold may also be referred to as the second classification threshold, and similarly, the second classification threshold may also be referred to as the first classification threshold. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0072] Payment transactions usually involve interactions between the client and the server. The client is responsible for interacting with the user, presenting data, receiving user input, and passing the user's operations to the server for processing; the server can include a business system for processing user operations, a payment system, and a payment institution.

[0073] Among them, the business system is responsible for receiving and processing user requests and interacting with other systems, such as the payment system and the payment institution. The payment system refers to an application program responsible for processing payment-related functions. When a user initiates a transaction business request, the payment system receives the request information and interacts with the payment institution, generates a payment interface or returns a payment link to the client to complete the payment operation; the payment system can process the callback notification of the payment result and update the order status. The payment institution refers to institutions such as banks and third-party payment companies that specifically provide payment services. They cooperate closely with the payment system and are responsible for processing user payment operations, fund settlement, and risk management, etc.

[0074] See Figure 1 As shown, the user triggers a business request through the client, such as a payment request or a refund request, and this business request will be sent to the server; after the business system of the server verifies the user identity and the business request is legal, the business system sends this business request to the payment system; the payment system generates a corresponding transaction instruction according to the received information and issues it to the payment institution, and this transaction instruction is used to instruct the payment institution to perform fund transfer processing; the payment institution performs corresponding payment operations according to the business information in the transaction instruction and returns the transaction result to the payment system; the payment system can further return this payment result to the business system, so that the business system returns the payment result to the client, so that the client can display the processing result of the business request.

[0075] In the process that the above payment system generates a transaction instruction according to the received information, due to possible data synchronization errors, network transmission failures, server system logic errors, etc., the business information used to describe the transaction content in the transaction instruction is inconsistent with the business request initiated by the user. For example, the transaction amount is incorrect, so that when the payment institution conducts a fund transfer based on this transaction instruction, a transaction error occurs, resulting in problems such as fund losses or insufficient transferred funds causing user complaints, affecting the user experience.

[0076] For example, if the user requests a refund amount of 100 yuan, assuming the actual refund amount in the generated transaction instruction is 101 yuan, it will cause a fund loss for the refunding party; or, if the actual refund amount in the generated transaction instruction is 99 yuan, the user loses 1 yuan, which may cause user complaints.

[0077] To solve the above technical problems, the present application provides a payment transaction method. After generating a transaction instruction at the server side and before performing fund transfer processing according to the transaction instruction, a new processing flow is added. This processing flow is implemented through the payment transaction method, and this method can be executed by the Figure 1 server side in the above. During the deployment process, this new processing flow can be integrated into the business system or payment system of the server side, or a bypass system can be separately set up at the server side. This bypass system is specifically used to interact with the business system and payment system of the server side to execute this processing flow.

[0078] See Figure 2 as shown, the payment transaction method may include the following steps:

[0079] S201, receiving the first service information generated when the client initiates a service request;

[0080] The service request refers to a payment transaction request for requesting the server side to perform fund transfer processing, so as to realize the transfer of funds between different accounts, such as payment requests, refund requests, transfer requests, etc. The service request may carry user input information.

[0081] The first service information is used to describe the attributes of the service request and is used to accurately transmit transaction-related data to the payment system of the server side, so that the payment system can correctly generate a transaction instruction. The parameter types included in the first service information are determined according to specific service requests. The first service information may include, but is not limited to, parameters such as service request identifiers, service request types, total transaction amounts, etc.

[0082] For example, if the service request is a transfer request, the first service information may include information such as a transaction ID, transfer amount, account identifiers and account types of the transfer-out account and transfer-in account. The transaction ID is used to uniquely identify the transfer request; or, for a service request that is a refund request, the first service information may include a refund order number, refund amount, payment account, receiving account, and payment result notification address.

[0083] The first service information can be generated by the server side. When the user triggers and initiates a service request through the client, the service request will be sent to the server side; when the server side receives the service request, it can determine the parameter types to be generated according to the service request, and generate different parameters as the first service information according to different payment methods, payment channels, business scenarios, and data information carried by the service request. And the server side can fill the first service information into the service request and send the updated service request to the above payment system.

[0084] In some specific scenarios, the first service information can be synchronously generated by the client when generating the service request. For example, in some distributed systems or asynchronous task processing, in order to improve the concurrent processing ability of the system and reduce the pressure on the server, the client can be allowed to generate some request information; another example is that if the client has a trusted computing environment and meets the relevant security requirements, it can be generated by the client. The first service information can be encapsulated into the service request by the client and sent to the server, or the client can send the first service information and the service request to the server separately.

[0085] After receiving or generating the first service information, the service system of the server can synchronize the first service information through methods such as message queues and HTTP requests, so as to receive the first service information corresponding to the service request.

[0086] For example, a message queue can be set in advance, and the server sends the first service information to the message queue. When it is detected that the message queue is updated, the first service information message is obtained from the queue. Or, if a communication interface for this payment transaction method is provided in advance, the server can encapsulate the first service message into an HTTP request and send it to the communication interface.

[0087] S202, receiving the instruction information included in the transaction instruction generated by the server according to the service request; the instruction information includes the second service information and an instruction identifier; the second service information and the first service information include parameters of the same type;

[0088] The transaction instruction refers to a command generated by the server for instructing a bank or a payment institution to perform a fund transfer process of a set amount. Different types of transaction instructions will be generated according to different service requests. The transaction instruction can include payment instructions, refund instructions, transfer instructions, cash withdrawal instructions, settlement instructions, etc.

[0089] After obtaining the service request and the first service information, the server can generate the transaction instruction based on the request parameters carried in the service request and the first service information. The transaction instruction can be generated through the following steps: Check and verify according to the first service information and the request parameters in the service request to ensure that the transaction amount is legal, the transaction account is valid, and necessary information such as user identity is verified; In response to successful verification, generate a unique instruction identifier to identify the instruction identifier and can be used to accurately identify and reference the transaction instruction in subsequent operations or queries; Construct the data structure of the transaction instruction according to the first service information and the request parameters included in the service request, and set the values of the member parameters in the data structure, such as transaction type, transaction amount, payee account information, payer account information, transaction description, etc. In some scenarios, the value of the service request identifier in the first service information can be directly determined as the instruction identifier.

[0090] For the case where the server includes a business system and a payment system, in one embodiment, after obtaining the service request and the first service information, the business system can fill the first service information into the service request and send the filled service request to the payment system. When receiving the service request, the payment system parses and extracts the first service information and other request parameters included in the service request and generates a transaction instruction.

[0091] After generating the transaction instruction, the server can encapsulate the service information included in the transaction instruction and the instruction identifier of the transaction instruction into a message, and send the message to the processing flow of this application through a message queue mechanism, HTTP communication, or other feasible data transmission methods, so as to receive the instruction information of the transaction instruction.

[0092] Since the first service information includes necessary transaction information, and the transaction instruction is used to instruct the payment institution to respond to the user's service request and contains all the information required for the transaction, the second service information used to describe the transaction content in the transaction instruction and the first service information include the same type of parameters. For example, both the first service information and the second service information include service type, transaction account information, transaction amount, etc. The transaction instruction is generated based on the request parameters included in the service request and the first service information. Normally, the values of the same type of parameters included in the second service information and the first service information in the transaction instruction are the same. Due to various possible abnormal reasons, the value of the same type of parameter in the second service information is different from that in the first service information, resulting in an error in the transaction responding to the service request.

[0093] S203. Verify the second service information according to the first service information and generate a verification result;

[0094] That is, according to the values of each parameter in the first service information, the values of the parameters of the same type in the second service information are compared with the values of the parameters in the first service information. The verification process can be implemented by comparing the values of each parameter one by one, comparing the hash values based on the parameter values, or other fast comparison methods.

[0095] When verifying the parameters of the same type in the second service information, it can be set to verify the values of all parameters of the same type. When the values of all parameters of the same type in the first service information and the second service information are the same, a verification result is generated indicating that the verification is successful; otherwise, if there is at least one value of the parameter of the same type that is different from the value in the first service information, a verification result is generated indicating that the verification fails.

[0096] Alternatively, it can also be set to verify the values of the target parameters that meet the set type among the parameters of the same type included in the second service information. When the values of all target parameters are the same as the values in the first service information, a verification result is generated indicating that the verification is successful; otherwise, if there is any value of the target parameter that is different from the value in the first service information, a verification result is generated indicating that the verification fails.

[0097] S204, send the instruction identifier and the verification result to the server, so that the server processes the transaction instruction indicated by the instruction identifier according to the verification result.

[0098] Pre-set different processing flows for the transaction instruction on the server according to different verification results in advance. After verifying the second service information included in the transaction instruction, a verification result for the transaction instruction is generated, and the verification result and the instruction identifier of the transaction instruction are fed back to the server. Thus, the server can determine the transaction instruction to be processed based on the instruction identifier and determine the process for the transaction instruction according to the verification result.

[0099] For example, it can be set that when the verification result indicates that the verification is successful, the transaction instruction is sent to a payment institution or a bank for the fund transfer process. For other verification results other than indicating successful verification, a transaction exception handling process can be executed to terminate the subsequent transaction processing of the transaction instruction, issue a transaction exception warning, and remind the corresponding personnel.

[0100] In the embodiments of the present disclosure, a new processing flow is integrated on the basis of the original transaction payment process. After generating a transaction instruction at the server, the instruction information included in the transaction instruction sent by the server is received, and the instruction information of the transaction instruction is verified according to the first service information corresponding to the service request initiated by the client, so that the server processes the transaction instruction according to the verification result. Thus, without overly affecting the original normal internal business logic, error information in the transaction instruction can be timely detected, reducing transaction failures or abnormal situations caused by incorrect transaction instructions, ensuring the safety of the user's funds and the trading interests are not damaged, enhancing the user's trust and satisfaction, and improving the efficiency of transactions.

[0101] In some embodiments, after receiving the first service information, the method may further include the following steps: storing the first service information in a local list. That is, a storage location for storing the first service information is pre-set in the local storage space, which may be in the form of a storage list, a storage queue, etc. After receiving the first service information, the first service information is stored in the specified storage space.

[0102] Based on the local queue storing the first service information, when at least two pieces of first service information corresponding to service requests are stored in the local list, as shown in Figure 3 shown, the step of verifying the second service information according to the first service information in step S201 may include the following steps:

[0103] S301, in the order of the storage time of each piece of first service information in the local list, verify the second service information according to each piece of first service information in turn;

[0104] That is, in the time sequence in which the first service information corresponding to each service request enters the local list, the values of the same type of parameters in the second service information are verified according to the values of the same type of parameters in each piece of first service information.

[0105] In one example, the verification of the second service information may start from the first service information that was stored in the local list most recently. After the verification fails, the first service information that was stored in the local list most recently is re-determined from the remaining first service information in the local list, and the above steps are repeated until the verification is successful or all the first service information in the local list has been traversed.

[0106] S302, in response to the verification result indicating successful verification, remove the first service information used when the verification is successful from the local list.

[0107] That is, for the second service information included in the received transaction instruction, if the parameter values of the same type in the second service information are consistent with the parameter values in the first service information corresponding to a service request in the local list, a verification result indicating successful verification is generated, and the first service information corresponding to the service request is removed from the local list.

[0108] In the embodiments of the present disclosure, by verifying in the storage time order of the first service information in the local list, it can be ensured that newer service requests are processed first and older service requests are processed later, which can maintain the sequential consistency of service processing and avoid situations where the processing order is chaotic or jumps.

[0109] In some embodiments, the same type of parameters included in the first payment information and the second payment information may include a service request identifier and at least one of a service type and a transaction amount. For different payment service types, payment parameters required for the service scenario may also be included. For example, for a cash withdrawal service, the user-requested cash withdrawal amount, service handling fee, and actual cash withdrawal amount may also be included. Based on the above same type of parameters, as Figure 4 shown, verifying the second service information and generating a verification result as described in any of the foregoing embodiments may be implemented by the following method:

[0110] S401, compare the service request identifiers in the first service information and the second service information;

[0111] The service request identifier is used to uniquely identify a service request initiated by a client. By comparing the service request identifiers in the first service information and the second service information, it can be quickly determined whether the first service information and the second service information belong to the same service request, and verification can be quickly implemented for the case of storing multiple first service information, improving the processing efficiency.

[0112] S402, in response to the service request identifiers being different, generate a first verification result indicating verification failure;

[0113] If the values of the service request identifiers in the first service information and the second service information are different, it indicates that the first service information and the second service information do not belong to the same service request, and further parameter comparison is not required, and it can be determined that the verification result based on the first service information indicates verification failure.

[0114] S403, in response to the service request identifiers being the same, sequentially compare the same type of parameters in the first service information and the second service information except the service request identifier;

[0115] That is, when the business request identifiers are the same, verify the values of other parameters in the same type of parameters included in the second business information except the business request identifier, and compare whether the values of each parameter are the same as the parameter values in the first business information.

[0116] For example, if the business request is a transfer request, and the same type of parameters include the business request identifier, payee account information, payer account information, and transfer amount, then when the values of the business request identifier in the first business information and the second business information are the same, verify the values of the payee information, payer information, and transfer amount in the second business information.

[0117] S404, when the values of the same type of parameters are all the same, generate a second verification result indicating successful verification.

[0118] In response to the values of all the same type of parameters included in the second business information being consistent with the parameter values in the first business information, the verification of the second business information for the transaction instruction is successful, and a second verification result indicating successful verification is generated.

[0119] In the embodiments of the present disclosure, by first determining whether the values of the business request identifiers are consistent, the verification logic is simplified, and the situation of failed verification can be quickly determined, avoiding waste of time and resources for comparing other parameters; at the same time, determining that the verification fails for the case where the values of the business request identifiers are inconsistent can also prevent misoperations or unauthorized access, improving security.

[0120] In some embodiments, as Figure 5 shown, verifying the second business information and generating a verification result described in any of the foregoing embodiments can also be implemented through the following steps:

[0121] S501, according to a preset hash algorithm, generate a first hash value corresponding to the same type of parameters in the first business information and a second hash value corresponding to the same type of parameters in the second business information;

[0122] A hash algorithm is an algorithm that maps input data to an output value of a fixed length, and can convert input data of any length into a hash value of a fixed length. Commonly used hash algorithms include MD5, SHA-1, SHA-256, etc. Based on the uniqueness of the hash value, that is, the same input data generates the same hash value, different input data generates different hash values, and a slight change in the input data will also cause a huge change in the hash value. Therefore, the hash value corresponding to the parameter value can be used to verify the values of the same parameters in the second business information.

[0123] If the values of the same type of parameters in the first service information and the second service information are the same, the input data is the same, and the first hash value corresponding to the value of the same type of parameters in the first service information is the same as the second hash value corresponding to the value of the same type of parameters in the second service information.

[0124] S502, in response to the first hash value being different from the second hash value, generate a first verification result indicating verification failure;

[0125] S503, in response to the first hash value being the same as the second hash value, generate a second verification result indicating verification success.

[0126] When the first hash value is the same as the second hash value, it means that the input data when calculating the hash value is the same, that is, the values of the same type of parameters in the first service information and the second service information are the same, and the verification result of the transaction instruction is verification success; conversely, if the first hash value is different from the second hash value, the values of the same type of parameters in the first service information and the second service information are not exactly the same, and the verification result of the transaction instruction is verification failure.

[0127] In the embodiments of the present disclosure, by calculating and comparing the hash values of the same type of parameter values in the first service information and the second service information, the comparison time and computing resources can be reduced, the verification logic can be simplified, and the complexity of processing the same type of parameter data in the service information can be avoided. At the same time, using hash values for comparison can hide the sensitive information of the parameter data in the service information, increase the security of the data, and prevent unauthorized access or tampering.

[0128] In some embodiments, before verifying the second service information in step S203 described above, as shown in Figure 6 it may further include the following steps:

[0129] S601, detect whether the instruction identifier in the instruction information is included in the local instruction identifier list; the instruction identifier list is used to store the instruction identifiers of the transaction instructions that have been verified.

[0130] For a transaction instruction whose instruction information has been verified and a verification result has been generated, store the instruction identifier of the transaction instruction in the local instruction identifier list and maintain it. The instruction identifier list is used to quickly determine whether the newly received instruction identifier is valid.

[0131] When a new instruction information is received, extract the instruction identifier in the instruction information; match the instruction identifier with each instruction identifier in the instruction identifier list. In response to a successful match, it means that the instruction identifier exists in the instruction identifier list, that is, the second service information in the instruction information has been verified.

[0132] S602, if so, generate a third verification result indicating repeated verification and send it to the server;

[0133] For the case where the received instruction information has been verified, generate a verification result indicating verification exception or repeated verification and send it to the server, so that the server generates a transaction exception warning for the transaction instruction indicated by the instruction identifier and terminates the subsequent transaction processing flow for the transaction instruction.

[0134] S603, if not, perform verification processing on the second service information.

[0135] When the instruction identifier of the received instruction information does not exist in the instruction identifier list, verify the second service information in the instruction information according to the normal logic process.

[0136] In the embodiments of the present disclosure, the instruction identifiers of the verified transaction instructions are stored in a local list. When the server receives the instruction information of a new transaction instruction, it can first check the local list to determine whether the instruction identifier has appeared before, so as to determine whether the instruction needs to be verified, avoiding repeated verification and processing of the same transaction instruction, preventing replay attacks, ensuring that each transaction instruction is only executed once, and thus enhancing the security of the entire transaction system.

[0137] In some embodiments, when the verification result indicates verification failure, the method may further include the step of sending the verification result to the client, that is, sending the verification result to the client so that the client can initiate the service request again in a set manner. Wherein, the verification result may include error information causing the verification failure.

[0138] After receiving the verification result indicating verification failure, the client can display the error information in the verification result to the user, so as to facilitate the user to understand the reason for the transaction exception and can prompt the user to initiate a transaction request again.

[0139] In the embodiments of the present disclosure, when the verification of the second service information in the transaction instruction fails, the verification result is sent to the client, so that the client can timely obtain the error information of the transaction instruction, thus avoiding learning the result of transaction failure after a long wait, increasing the transparency of the transaction process, and improving the user experience.

[0140] Next, to enable those skilled in the art to better understand the method provided by the present application, in this embodiment, taking the business scenario of a user initiating a bank card transfer as an example, the payment transaction method provided by the present application is described.

[0141] In the scenario of bank card transfer service, the user initiates a transfer request on a client terminal device such as a mobile phone, tablet, computer, etc., to transfer the specified funds in Bank Card 1 to Bank Card 2. This transfer request will be sent by the client to the server. The transfer request may include the transfer amount, payee account information, payer account information, and transfer purpose, and may also include security authentication information such as verification codes and payment passwords. Among them, the payer is Bank Card 1 and the payee is Bank Card 2. In this embodiment, the server may include a business system, a payment system, and a payment institution, and a bypass system is newly added to the server. This bypass system is used to interact with the business system and the payment system to execute the payment transaction method provided in this application.

[0142] See Figure 7 As shown, the transfer request initiated by the user on the client will be sent to the business system of the server. After receiving this transfer request, when the business system verifies that the transfer request is reasonable, it generates the first transfer business information according to this transfer request, which may include but is not limited to transfer request identification, transfer date, transfer handling fee, total amount deducted from the payer's account, total amount added to the payee's account, ID card numbers and mobile phone numbers of the payer and the payee.

[0143] This first transfer business information can be synchronized by the business system to the bypass system and the payment system, and the first business information can be sent to the bypass system through a pre-set message queue. During the process of synchronizing to the payment system, the business system can include this first transfer business information in the transfer request and send this transfer request to the payment system of the server through HTTP communication.

[0144] After receiving this transfer request, the payment system parses the transfer request to obtain this first transfer business information and other relevant parameters, generates a corresponding transfer instruction based on this first transfer business information and other parameters included in the request, and assigns a unique transfer instruction identification to this transfer instruction. The transfer request identification can be directly used as the transfer instruction identification. This transfer instruction includes the second transfer business information required for executing the transfer, such as transfer request identification, transfer amount, transfer purpose, transfer type, account names, account numbers, and bank branch names of the payer and the payee. Among them, the transfer type includes immediate transfer or reserved transfer.

[0145] After the transfer instruction is generated, the operation of sending the transfer instruction to the payment institution is temporarily interrupted. The second transfer business information and the instruction identification included in the transfer instruction are encapsulated into a transfer message and sent to the bypass system through a message queue or other communication methods. The bypass system can pre-set an interception node in the process of generating the transfer instruction in the payment system, so as to monitor and intercept the process when the transfer instruction is generated to perform information verification first.

[0146] The bypass system stores the received first transfer service information in a local list. For different types of service requests, they can be stored in different local lists according to the service request types. When receiving a transfer message from the payment system, the bypass system is triggered to verify the second transfer service information in the transfer message based on the stored first service information corresponding to the transfer type, and send the generated verification result and the corresponding instruction identifier to the payment system. Before performing the verification, the bypass system can determine whether the transfer message has been verified based on the instruction identifier in the transfer message, so as to avoid repeated verification and multiple executions of the same transfer request.

[0147] The parameter types that need to be verified for the transfer request can be preset in advance. When a local list stores the first transfer service information corresponding to a transfer request, the second service information is directly compared with the values of the set type parameters included in the first service information to generate the corresponding verification result. When the local list stores the first transfer service information of at least two transfer requests, the second service information can be compared with the set type parameters in each first service information in the storage time order of the first transfer service information stored in the local list.

[0148] For example, the parameter types that need to be verified, i.e., the set type parameters, can include the transfer request identifier, transfer amount, account numbers of the payer and payee. When receiving a transfer message from the payment system, the values of the transfer request identifier, transfer amount, account numbers of the payer and payee in the second service message in the transfer message are sequentially compared with the values of the same parameters in the first service message. When the values of these four parameters are all the same, a first verification result indicating successful verification is generated. If there is any parameter value inconsistency, a first verification result indicating failed verification is generated.

[0149] After generating the verification result, the bypass system can also send the verification result to the service system, and the service system performs interactive processing with the client based on the verification result. For example, the service system can generate a prompt page based on the verification result according to the set processing flow and send it to the client, so as to display the prompt page on the client, enabling the user to clarify the transaction progress and / or the reason for failure. Further, a processing method for transaction failure can be popped up for the user to refer to.

[0150] In the payment system, the processing methods for transfer instructions corresponding to different verification results are preset. After receiving the verification result, if the verification result indicates successful verification, the payment system sends the transfer instruction indicated by the instruction identifier to the bank or payment institution. Then, the bank or payment institution deducts the corresponding amount from the payer's account according to the payee account information and transfer amount specified in the transfer instruction, transfers the amount to the payee's account, and updates the account balance information of Card 1 and Card 2 accordingly after the transfer. At the same time, the bank or payment institution generates a transaction result and forwards it to the payment system, which then forwards it to the business system, so as to return the payment result to the client for the user to clarify the payment status. In the case where the verification result indicates verification failure, the transfer processing operation based on the transfer instruction is terminated, and an abnormal transfer alarm can be generated according to the error parameters carried in the verification result, and enter the abnormal transfer processing process, such as sending the alarm information to the corresponding personnel for manual verification and correction.

[0151] For other payment business scenarios, such as the cash withdrawal request of the user requesting to withdraw change to the bank card, the process is the same as the above payment transaction method. First, receive the first cash withdrawal service information generated for the cash withdrawal request synchronized by the business system of the server, and receive the instruction information included in the cash withdrawal instruction generated by the payment system. Assuming that the cash withdrawal involves the calculation of handling fees, the values of parameters such as the cash withdrawal request ID, bank card number, requested cash withdrawal amount, handling fees to be deducted, and the actual deducted amount from the change fund pool included in the second cash withdrawal service information in the first cash withdrawal service information can be compared. When the values of all parameters are the same, the payment institution executes the cash withdrawal process according to the cash withdrawal instruction and updates the account balance.

[0152] In the embodiment of the present disclosure, by deploying a bypass system for executing the above payment transaction method on the server side, without affecting the normal internal business logic of the server system, the node information is intercepted before the payment system generates a transfer instruction to execute fund transfer for information verification of the transaction instruction, reducing transaction failures or abnormal situations caused by incorrect transaction instructions. For payment services involving fund calculations such as user cash withdrawal, transfer, and refund services after using coupons, the fund transactions are made more stable, ensuring that the user's fund security and transaction interests are not damaged, enhancing the user's trust and satisfaction, and improving the transaction efficiency.

[0153] Corresponding to the embodiment of the foregoing payment transaction method, see Figure 8 As shown, the present application also provides an embodiment of a payment transaction device, and the device includes:

[0154] A first service information acquisition module 801, configured to receive the first service information generated when the client initiates a service request;

[0155] An instruction information acquisition module 802, configured to receive instruction information included in a transaction instruction generated by a server according to the service request; the instruction information includes second service information and an instruction identifier; the second service information and the first service information include the same type of parameters;

[0156] A second service information verification module 803, configured to verify the second service information according to the first service information to generate a verification result;

[0157] A transaction instruction processing module 804, configured to send the instruction identifier and the verification result to the server, so that the server processes the transaction instruction indicated by the instruction identifier according to the verification result.

[0158] In some embodiments, after receiving the first service information, the apparatus includes: storing the first service information in a local list;

[0159] When the local list stores first service information corresponding to at least two service requests, the second service information verification module is specifically configured to:

[0160] Verify the second service information according to each piece of first service information in sequence according to the storage time of each piece of first service information in the local list;

[0161] In response to the verification result indicating successful verification, remove the first service information used when the verification is successful from the local list.

[0162] In some embodiments, for any of the foregoing apparatus embodiments, the same type of parameters at least includes a service request identifier, and at least includes at least one of a service type and a transaction amount; the second service information verification module is specifically configured to:

[0163] Compare the service request identifiers in the first service information and the second service information;

[0164] In response to the service request identifiers being different, generate a first verification result indicating verification failure;

[0165] In response to the service request identifiers being the same, compare the same type of parameters other than the service request identifier in the first service information and the second service information in sequence;

[0166] In the case where the values of the same type of parameters are all the same, generate a second verification result indicating successful verification.

[0167] In some embodiments, for any of the foregoing apparatus embodiments, the second service information verification module is specifically configured to:

[0168] Generate a first hash value corresponding to the same type of parameters in the first service information and a second hash value corresponding to the same type of parameters in the second service information according to a preset hash algorithm;

[0169] In response to the first hash value being different from the second hash value, generate a first verification result indicating verification failure;

[0170] In response to the first hash value being the same as the second hash value, generate a second verification result indicating verification success.

[0171] In some embodiments, before verifying the second service information, the device further includes:

[0172] Detect whether the instruction identifier in the instruction information is included in the local instruction identifier list; the instruction identifier list is used to store the instruction identifiers of the transaction instructions that have been verified;

[0173] If so, generate a third verification result indicating repeated verification and send it to the server;

[0174] If not, perform verification processing on the second service information.

[0175] In some embodiments, the device may further include:

[0176] In the case where the verification result indicates verification failure, send the verification result to the client so that the client can re-initiate the service request in a set manner.

[0177] The implementation processes of the functions and roles of each unit in the above device are specifically described in the implementation processes of the corresponding steps in the above method, and will not be repeated here.

[0178] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0179] This application embodiment also provides an electronic device, and the structural schematic diagram of the electronic device is as Figure 9As shown, the electronic device 900 includes at least one processor 901, a memory 902, and a bus 903. At least one processor 901 is electrically connected to the memory 902. The memory 902 is configured to store at least one computer-executable instruction, and the processor 901 is configured to execute the at least one computer-executable instruction, thereby performing the steps of any payment transaction method provided in any one embodiment or any optional implementation manner of the present application.

[0180] Further, the processor 901 can be an FPGA (Field-Programmable Gate Array), or other devices with logical processing capabilities, such as an MCU (Microcontroller Unit) or a CPU (Central Processing Unit).

[0181] An embodiment of the present application also provides another readable storage medium storing a computer program, which is used to implement the steps of any payment transaction method provided in any one embodiment or any optional implementation manner of the present application when being executed by a processor.

[0182] The readable storage medium provided by the embodiment of the present application includes, but is not limited to, any type of disk (including floppy disks, hard disks, optical disks, CD-ROMs, and magneto-optical disks), ROM (Read-Only Memory), RAM (Random Access Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, magnetic cards, or optical cards. That is, the readable storage medium includes any medium that stores or transmits information in a form readable by a device (such as a computer).

[0183] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the acts recited in the claims can be performed in a different order and still achieve the desired result. In addition, the processes depicted in the figures are not necessarily the specific order or sequential order shown to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0184] Although this specification contains many specific implementation details, these should not be construed as limiting the scope of any invention or the scope of what is claimed, but rather are mainly used to describe the features of specific embodiments of a particular invention. Certain features described in multiple embodiments within this specification can also be implemented in combination within a single embodiment. On the other hand, the various features described in a single embodiment can also be implemented separately in multiple embodiments or in any suitable sub-combination. Additionally, although features may operate in certain combinations as described above and may even be initially claimed as such, one or more features from the claimed combination can in some cases be removed from that combination, and the claimed combination can be directed to a sub-combination or a variation of a sub-combination.

[0185] The above are only the preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A payment transaction method, characterized in that, The method includes: Receiving first service information generated when a client initiates a service request; Receiving instruction information included in a transaction instruction generated by a server according to the service request; the instruction information includes second service information and an instruction identifier; the second service information and the first service information include the same type of parameters; Verifying the second service information according to the first service information to generate a verification result; Sending the instruction identifier and the verification result to the server so that the server processes the transaction instruction indicated by the instruction identifier according to the verification result.

2. The method according to claim 1, wherein After receiving the first service information, the method includes: storing the first service information in a local list; When the local list stores first service information corresponding to at least two service requests, the verifying the second service information according to the first service information includes: Verifying the second service information according to each piece of first service information in sequence according to the storage time of each group of first service information in the local list; In response to the verification result indicating successful verification, removing the first service information used at the time of successful verification from the local list.

3. The method according to claim 1 or 2, characterized in that, The same type of parameters at least includes a service request identifier, and at least includes at least one of a service type and a transaction amount; the verifying the second service information to generate a verification result includes: Comparing the service request identifiers in the first service information and the second service information; In response to the service request identifiers being different, generating a first verification result indicating failed verification; In response to the service request identifiers being the same, sequentially comparing the same type of parameters other than the service request identifier in the first service information and the second service information; When the values of the same type of parameters are all the same, generating a second verification result indicating successful verification.

4. The method according to claim 1 or 2, characterized in that, The verifying the second service information to generate a verification result includes: Generating a first hash value corresponding to the same type of parameters in the first service information and a second hash value corresponding to the same type of parameters in the second service information according to a preset hash algorithm; In response to the first hash value and the second hash value being different, generating a first verification result indicating failed verification; In response to the first hash value and the second hash value being the same, generating a second verification result indicating successful verification.

5. The method according to claim 1, characterized in that Before verifying the second service information, the method further includes: Detecting whether the instruction identifier list locally includes the instruction identifier in the instruction information; the instruction identifier list is used to store instruction identifiers of transaction instructions that have been verified; If so, generating a third verification result indicating repeated verification and sending it to the server; If not, performing verification processing on the second service information.

6. The method according to claim 1, characterized in that, The method further includes: In the case where the verification result indicates failed verification, sending the verification result to the client so that the client re-initiates the service request in a set manner.

7. A payment transaction device, characterized in that, The device includes: A first service information acquisition module, configured to receive first service information generated when a client initiates a service request; An instruction information acquisition module, configured to receive instruction information included in a transaction instruction generated by a server according to the service request; the instruction information includes second service information and an instruction identifier; the second service information and the first service information include the same type of parameters; A second service information verification module, configured to verify the second service information according to the first service information to generate a verification result; A transaction instruction processing module, configured to send the instruction identifier and the verification result to the server, so that the server processes the transaction instruction indicated by the instruction identifier according to the verification result.

8. The device according to claim 7, wherein After receiving the first service information, the apparatus further includes: storing the first service information in a local list; When the local list stores first service information corresponding to at least two service requests, the second service information verification module is specifically configured to: Verify the second service information according to each piece of first service information in sequence according to the storage time of each group of first service information in the local list; In response to the verification result indicating successful verification, remove the first service information used at the time of successful verification from the local list.

9. An electronic device, characterized in that, Including: A processor and a memory; The memory is configured to store a computer program; The processor is configured to execute the method for payment transactions according to any one of claims 1-6 by calling the computer program.

10. A readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the payment transaction method according to any one of claims 1-6.

Images