Multi-stage security verification method and device for decoupling payment result from user login state

Abstract

The embodiment of the specification provides a multi-stage secure verification method and device for decoupling payment results and user login states, wherein the method comprises the following steps: after a user initiates a payment request and the payment is successful, in response to a payment callback notification sent by a payment platform, callback data is analyzed, and payment result decoupling storage is performed; it is judged whether it is a payment-on-behalf-of scenario, if yes, a payment user unique identifier is added to an authorized operator list of the order; a front-end initiated order performance request is received, the payment result of the order is queried, and the current state of the order on the payment platform and the payment user identifier are obtained from a payment platform order query interface; the unique identity identifier in the front-end performance request, the payment user identifier in the payment result, and the payment user identifier fed back by the payment platform are compared with each other, and it is dynamically judged whether the order is operated by the payment person himself or by a user authorized by the payment person and having the same identity based on the authorized operator list.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular to a multi-stage security verification method and apparatus that decouples payment results from user login status. Background Technology

[0002] With the widespread adoption of mobile payments, payment methods such as WeChat Pay and Alipay have become core components of e-commerce and O2O businesses. After a user successfully pays, the merchant system needs to perform subsequent operations (such as shipping or refunding) based on the payment result. The current mainstream processing flow is as follows: the user initiates a payment on the front end, the merchant's back end calls the payment platform's order placement interface, passing in the currently logged-in user's identity identifier (such as OpenID), and after successful payment, the payment platform asynchronously notifies the merchant's back end of the payment result. The merchant's back end updates the order status based on the callback, and then the front end user can initiate operations such as shipping.

[0003] However, this process faces several technical challenges in practice, including: A user's login status may change (e.g., logging out and logging back in), leading to inconsistencies between the identity identifier in subsequent requests and the identity identifier used during payment. Payment callbacks may experience network latency, causing the front-end to display a successful payment status prematurely before the back-end receives confirmation, resulting in data inconsistencies. Malicious users may tamper with request data (e.g., forging someone else's OpenID) to attempt to fraudulently claim goods. In legitimate payment scenarios (e.g., children paying for their parents), the payer and the order placer are not the same person, and rigid verification can hinder the operation.

[0004] The core of the above problems lies in the lack of an effective decoupling and verification mechanism between payment results and user login status, and the existing solutions fail to balance security and business flexibility.

[0005] To address the aforementioned technical problems, the following technical solutions exist in the prior art: Option 1: Simple Login Status Validation: When a user makes a payment, the openid of their current login status is recorded in the order. During subsequent shipment, the openid in the request is directly compared to the openid recorded in the order. This option is common in small e-commerce systems and is simple to implement, but it has significant drawbacks: it cannot handle changes in login status. If a user logs out and then logs back in after payment, even if it's the same person, the transaction will be blocked, leading to false positives; it also cannot prevent malicious tampering, as attackers can easily bypass the check by forging a valid openid.

[0006] Option 2: Payment Callback Data Overwrite: After a user successfully pays, the original openid in the order is overwritten with the openid from the callback (the original openid was the openid from the login state at the time the order was placed). Subsequent operations will use this overwritten openid. This option exists in some open-source e-commerce systems. Although this option overwrites the original openid with the callback openid, it ignores legitimate scenarios where the "order placer" and the "payer" may be different (such as payment on behalf of another). After overwriting, the order placer will never be able to process the order again, and the payer will be unable to process the order if they are not logged in, thus hindering business operations.

[0007] Option 3: Relying solely on real-time queries from the payment platform: For each fulfillment request, the payment platform's order query interface is called in real-time, using the `openid` returned by the interface as the sole criterion, ignoring the `openid` in the front-end request. This option emphasizes real-time performance but ignores the legitimate context that the front-end request itself may carry. In other words, this option relies solely on real-time queries from the payment platform. While highly accurate, it cannot identify authorization / delegation scenarios, and each query increases the overhead of interface calls. Furthermore, if the payment platform's data is tampered with (extremely rare) or there is a network anomaly, it can lead to service unavailability.

[0008] In summary, existing technical solutions fail to systematically address the four intertwined issues of login state changes, asynchronous latency, security attacks, and payment compatibility. Specifically: 1. Payment results due to user login state changes (logout, re-login) do not match the identity of subsequent operations, leading to business operation failures or misjudgments. 2. Delayed or lost asynchronous payment callbacks cause inconsistencies between the front-end state and the actual payment result on the back-end, resulting in sensitive operations not being executed in a timely manner or executing incorrectly. 3. Malicious tampering with front-end data leads to security vulnerabilities such as "A pays, B receives goods." 4. Rigid verification mechanisms are incompatible with legitimate business scenarios such as payments on behalf of parents (e.g., children paying for their parents), impacting user experience. Therefore, a multi-stage, multi-dimensional, flexible, and scalable verification system is urgently needed. Summary of the Invention

[0009] The purpose of this invention is to provide a multi-stage security verification method and apparatus that decouples payment results from user login status, thereby solving the aforementioned problems in the prior art.

[0010] This invention provides a multi-stage security verification method that decouples payment results from user login status, including: Step 1: After the user initiates a payment request and the payment is successful, the merchant server responds to the payment callback notification sent by the payment platform, parses the callback data, and performs decoupled storage of the payment result. Step 2: Determine if it is a payment on behalf scenario. If it is, add the unique identifier of the payment user to the list of authorized operators for this order. Step 3: Receive the order fulfillment request initiated by the front end, query the payment result of the order, and obtain the current status of the order on the payment platform and the payment user identifier from the order query interface of the payment platform. Compare the unique identity identifier in the fulfillment request from the front end, the payment user identifier in the payment result, and the payment user identifier fed back by the payment platform. Based on the authorized operator list, dynamically determine whether the order was operated by the payer or a user authorized by the payer with the same identity.

[0011] This invention provides a multi-stage security verification device that decouples payment results from user login status, comprising: The payment result processing module is used to respond to the payment callback notification sent by the payment platform through the merchant server after the user initiates a payment request and the payment is successful, parse the callback data, and perform decoupled storage of the payment result; The authorization management module is used to determine whether it is a payment on behalf scenario. If it is determined to be a payment on behalf scenario, the unique identifier of the payment user is added to the list of authorized operators for this order. The multi-source comparison and authorization verification engine is used to receive the order fulfillment request initiated by the front end, query the payment result of the order, and obtain the current status of the order on the payment platform and the payment user identifier from the order query interface of the payment platform. It compares the unique identity identifier in the fulfillment request of the front end, the payment user identifier in the payment result, and the payment user identifier fed back by the payment platform, and dynamically determines whether the order is operated by the payer or a user authorized by the payer with the same identity based on the list of authorized operators.

[0012] This invention also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the multi-stage security verification method that decouples the payment result from the user login state.

[0013] This invention also provides a computer-readable storage medium storing an information transmission implementation program. When the program is executed by a processor, it implements the steps of the multi-stage security verification method that decouples the payment result from the user login state.

[0014] By employing this invention, the "Payment in Progress" intermediate state resolves the front-end and back-end state conflicts caused by asynchronous callback delays, ensuring that sensitive operations are only executed after payment confirmation. Multi-source mandatory comparison (three elements) effectively prevents identity confusion and malicious tampering; the authorization verification mechanism ensures that only the payer or authorized person can operate the order; dynamic trust assessment further mitigates risks arising from excessive time or environmental changes. The authorization delegation mechanism perfectly supports legitimate scenarios such as payment on behalf of others, avoiding user experience issues caused by blanket blocking, while ensuring security through fine-grained permission control. The distributed consensus mechanism enables the system to make correct decisions even when some nodes fail or are compromised, improving overall reliability. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in one or more embodiments of this specification or in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of a multi-stage security verification method for decoupling payment results from user login state, according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating the decoupled storage and status management of payment results according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the construction process of the authorization delegation mechanism according to an embodiment of the present invention; Figure 4 This is a flowchart of the multi-source comparison and authorization verification process for performance requests according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the three-element comparison logic of an embodiment of the present invention; Figure 6 This is a flowchart of the dynamic trust assessment and hierarchical decision-making process according to an embodiment of the present invention; Figure 7 This is a flowchart of the distributed consensus verification process in a high-security scenario according to an embodiment of the present invention; Figure 8 This is a schematic diagram of a multi-stage security verification device for decoupling payment results from user login status according to an embodiment of the present invention; Figure 9 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0018] The technical terms involved in the embodiments of the present invention will be explained below.

[0019] Definitions of abbreviations and key terms Openid (open identity): A unique identity identifier assigned to users by open platforms such as WeChat / Alipay. It is unique and unchanging within the same application (appid). Appid (application identity) is a unique identifier for an application, used to distinguish different applications. Payment callback is a mechanism by which the payment platform (WeChat / Alipay) asynchronously notifies the merchant's server of the payment result after the user has successfully made a payment. Login state refers to a user's login status within an application. It is typically maintained through a session or token and includes the current user's identity information. Fulfillment operation refers to the business operations that need to be performed after payment is completed, such as shipping, refunding, and verification. Three-factor comparison is a method for comparing the consistency of the user identifier in the current request, the payment user identifier stored in the order, and the user identifier queried in real time by the payment platform. Authorization delegation is a mechanism by which a payer authorizes other users to perform performance operations on its behalf. The intermediate state is when the order is in the "paying" state before the payment success callback arrives. It is used to lock sensitive operations. Trust value is a numerical value calculated based on factors such as time decay and environmental similarity, used to measure the risk level of the current request; Distributed consensus is a mechanism in which multiple independent nodes confirm the consistency of the same data, and is used to prevent single-point data tampering.

[0020] Method Implementation Examples According to embodiments of the present invention, a multi-stage security verification method decoupling payment results from user login state is provided. Figure 1 This is a flowchart of a multi-stage security verification method for decoupling payment results from user login state, as described in an embodiment of the present invention. Figure 1 As shown, the multi-stage security verification method for decoupling payment results from user login state according to an embodiment of the present invention specifically includes: Step S101: After the user initiates a payment request and the payment is successful, the merchant server responds to the payment callback notification sent by the payment platform, parses the callback data, and performs decoupled storage of the payment result; specifically including: When a user initiates a payment request, the backend creates an order and sets the order status to "paying". Lock down all operations involving funds or sensitive data; Call the payment platform's order placement interface and pass in the current login status, i.e., the login status openid_order when initiating the payment; After successful payment, the merchant server receives a payment callback notification asynchronously sent by the payment platform; The merchant server parses the callback data, extracts the payment user's unique identifier openid_pay, payment time, environmental characteristics at the time of payment, and the user identifier openid_order at the time of order placement, and stores them in the order database. The order status is updated to "pending fulfillment", and all operations involving funds or sensitive data are unlocked.

[0021] Step S102: Determine if it is a payment on behalf scenario. If it is, add the unique identifier of the paying user to the authorized operator list for this order; specifically including: Automatically determine whether openid_pay is equal to openid_order. If openid_pay is not equal to openid_order, it is determined to be a payment on behalf of another person. If openid_pay is equal to openid_order, it is determined to be a payment made by the person themselves. The openid_pay is automatically added to the authorized operator list authorized_openids for this order. Alternatively, the payer can manually add other delegates to the authorized operator list through the user-guided interface and set the operation permissions for each delegate. The authorized operator list is then persistently stored.

[0022] Step S103: Receive the order fulfillment request initiated by the front end, query the payment result of the order, and obtain the current status and payment user identifier of the order on the payment platform from the payment platform's order query interface. Compare the unique identifier in the front end's fulfillment request, the payment user identifier in the payment result, and the payment user identifier returned by the payment platform. Based on the authorized operator list, dynamically determine whether the order was operated by the payer or a user authorized by the payer with the same identity. Specifically, this includes: Receive a fulfillment request initiated by the front end, wherein the fulfillment request carries the openid_req of the current login state, the order number and the current environment characteristics; Based on the order number, retrieve the openid_pay, openid_order, authorized_openids, payment time, and payment environment characteristics of the order from the database in China; In real time, call the payment platform's order query interface to obtain the current status of the order on the payment platform and the payment user identifier openid_wx; Check if openid_req is equal to openid_pay and if openid_pay is equal to openid_wx. If they are, the operation is performed by the authorized person and the payment is allowed. If they are not, check if openid_req is in the authorized operator list authorized_openids and if openid_req is equal to openid_wx. If they are, the operation is performed by the authorized person and the authorizer is the actual payer, so the payment is allowed. If they are not, intercept the request, log the exception and trigger an alarm.

[0023] In embodiments of the present invention, the following processing may also be included: Calculate the Trust value for the current request using Formula 1 or a machine learning model: Formula 1; Where BaseScore is the basic trust score, Δt is the time difference between payment completion and the current request, and λ is the attenuation coefficient set according to the business requirements. The similarity between the current environmental characteristics and the payment environment characteristics; Based on the Trust value, a tiered decision is executed: if Trust is greater than or equal to a first predetermined threshold, the application is automatically cleared; if Trust is greater than or equal to a second predetermined threshold but less than the first predetermined threshold, an enhanced verification process is triggered; if Trust is less than the second predetermined threshold, the application is blocked and transferred to manual review, wherein the first predetermined threshold is greater than the second predetermined threshold. Specifically, triggering the enhanced verification process includes: triggering verification processes using SMS verification codes, fingerprints, and / or facial recognition.

[0024] For high-value orders that meet the predetermined value rules or high-risk operations that meet the predetermined risk rules, a distributed consensus mechanism is activated: the predetermined key order information is stored simultaneously on multiple independent nodes, wherein the predetermined key order information includes: openid_pay, order amount, and order status hash value; the multiple independent nodes specifically include: a master database, a read-only slave database, and a blockchain evidence storage node; When a payment request is made, the payment openid is queried from all nodes. A predetermined algorithm is used for voting. Only when more than a predetermined number of nodes return a consistent result that matches the requested openid is the request allowed. Otherwise, an enhanced verification process is triggered or the request is blocked and transferred to manual review. The predetermined algorithm includes the Raft algorithm or the Byzantine fault tolerance algorithm.

[0025] As can be seen from the above technical solutions, the embodiments of the present invention adopt a fusion mechanism of multi-source data forced comparison and authorization verification: comparing the front-end request openid, the order storage openid_pay, and the payment platform's real-time openid_wx, and combining them with the authorization list for dynamic judgment, which is the core verification logic of the present invention. The introduction of the authorization delegation mechanism in the embodiments of the present invention: automatically identifying payment scenarios and constructing an authorization list, supporting fine-grained permission control, enabling the solution to be compatible with legitimate business models while ensuring security. In the embodiments of the present invention, the "paying" intermediate state and sensitive operation locking: locking operations before the payment callback arrives solves the data chaos problem caused by asynchronous delays. The embodiments of the present invention also adopt a dynamic trust evaluation model: introducing time decay and environmental similarity to calculate trust values, realizing hierarchical decision-making, and balancing security and user experience. The embodiments of the present invention also adopt a distributed consensus verification mechanism (optional): in high-security scenarios, multi-node consensus is used to prevent single-point data tampering and improve system robustness.

[0026] The technical solutions of the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0027] like Figures 2-7 As shown, this embodiment of the invention provides a multi-stage security verification method that decouples payment results from user login status, including the following steps: Step 1: Decouple payment result storage from state management. Figure 2 This demonstrates the complete process from user-initiated payment to payment callback completion, including locking the "Payment in Progress" status, parsing callback data, storing payment information, and updating the status. Figure 2As shown, after a user initiates a payment request, the order immediately enters the "Payment in Progress" state, and all operations involving funds or sensitive data (such as shipping or refunds) are locked. Upon successful payment, the payment platform (WeChat / Alipay) asynchronously sends a payment callback notification to the merchant server. The merchant server parses the callback data, extracting the payment user's unique identifier (denoted as openid_pay), payment time, environmental characteristics at the time of payment (device fingerprint, IP address, etc., requiring user authorization), and the user identifier at the time of order placement (denoted as openid_order, i.e., the login state at the time of payment initiation). This information is stored in the order database, the order status is updated to "Pending Fulfillment," and the lock is released.

[0028] In practical applications, other identity identifiers can be used instead of OpenID: in non-WeChat / Alipay payment scenarios, mobile phone numbers, email addresses, ID card numbers, etc., can be used as unique user identifiers, with the same principle. The verification logic can be adapted to replace the identifier in the "three-factor authentication" with the corresponding identifier.

[0029] Step 2: Establish an authorization and delegation mechanism. Figure 3 This demonstrates the process of automatically identifying payment on behalf scenarios, constructing authorization lists, and setting permissions. For example... Figure 3 As shown, the system automatically determines whether it is a payment on behalf of another: if openid_pay ≠ openid_order, it is determined to be a payment on behalf of another. The system automatically adds openid_pay to the authorized operator list authorized_openids for this order, or the payer can manually add other authorized persons (such as the order placer) through the user-guided interface, and can set the operation permissions for each authorized person (such as only able to ship, only able to view, able to refund, etc.). The authorization relationship is persistently stored.

[0030] In practical applications, authorization can be delegated through a "temporary authorization code" mechanism: the payer generates a one-time authorization code, which the delegate uses to operate. The authorization code can be set with an expiration period and a scope of permissions, replacing a fixed list of authorizations.

[0031] Step 3: Forced comparison and authorization verification of multi-source data for performance requests. Figure 4 This demonstrates the logic for retrieving information from three independent data sources and performing core validations after receiving a shipment request. For example... Figure 4As shown, the system receives fulfillment requests (such as shipping requests) initiated by the frontend. These requests carry the current login status's `openid_req`, order number, and current environment characteristics. Based on the order number, the system queries the database for the order's `openid_pay`, `openid_order`, `authorized_openids`, payment time, and payment environment characteristics. Simultaneously, it calls the payment platform's order query interface in real time to obtain the order's current status on the payment platform (e.g., "payment successful") and the payment user identifier `openid_wx` (for secondary confirmation). The core verification logic is as follows: Figure 5 As shown. This logic ensures that only the payer or a user authorized by the payer with the same identity can process the order.

[0032] Step 4: Dynamic Trust Assessment and Tiered Decision Making (Optional Enhancement) Figure 6 This demonstrates how, after the three-factor authentication is successful, a trust score is calculated and tiered decisions are made based on that trust score. Figure 6 As shown, after passing the above verification, the trust value of the current request is further calculated:

[0033] Where BaseScore is the basic trust score (e.g., 100), Δt is the time difference between payment completion and the current request, λ is the attenuation coefficient (set according to business), and Sim is the similarity between the current environment characteristics and the payment environment characteristics (between 0 and 1).

[0034] Ranked decisions are made based on trust values: Trust ≥ 90: Automatic release.

[0035] 60 ≤ Trust < 90: Trigger enhanced verification (such as SMS verification code, facial recognition).

[0036] Trust < 60: Intercept and transfer to manual review.

[0037] In this embodiment of the invention, machine learning models (such as logistic regression and random forest) can be used to replace the formula calculation. The input features include time, environment, historical behavior, etc., and the output risk probability is then mapped to a trust value classification.

[0038] Step 5: Distributed consensus verification in high-security scenarios (optional) Figure 7 The demonstration shows the process of using a distributed consensus mechanism for high-value orders, involving multi-node queries and Byzantine fault-tolerant voting, such as... Figure 7As shown, a distributed consensus mechanism is used for high-value orders or high-risk operations. Key order information (such as openid_pay, amount, and status hash) is stored simultaneously on multiple independent nodes (such as the master database, read-only slave databases, and blockchain evidence storage nodes). When a fulfillment request is made, the payment openid is queried from all nodes, and a Byzantine fault-tolerant algorithm (such as PBFT) is used for voting. Only when more than 2 / 3 of the nodes return a consistent result that matches the requested openid is the request allowed to proceed.

[0039] In this invention, the Raft algorithm can be used instead of the Byzantine fault-tolerant algorithm, which is suitable for trusted node environments (such as internal private chains) and reduces implementation complexity.

[0040] It should be noted that, in addition to e-commerce delivery, the embodiments of the present invention can also be applied to: refund operations, electronic ticket verification, membership rights redemption, financial transaction confirmation, and any other scenario that requires payment and fulfillment of obligations.

[0041] In summary, the beneficial effects of the embodiments of the present invention are as follows: 1. Improved data consistency: By using the "Payment in progress" intermediate state, the conflict between the front-end and back-end states caused by asynchronous callback delays is resolved, ensuring that sensitive operations are only executed after the payment result is confirmed.

[0042] 2. Enhanced security: Multi-source mandatory comparison (three elements) effectively prevents identity confusion and malicious tampering; the authorization verification mechanism ensures that only the payer or authorized person can operate the order; dynamic trust assessment further prevents risks caused by excessive time or environmental changes.

[0043] 3. Business compatibility optimization: The authorization and delegation mechanism perfectly supports legitimate scenarios such as payment on behalf of others, avoiding user experience problems caused by a one-size-fits-all approach to blocking, while ensuring security through fine-grained permission control.

[0044] 4. System robustness: The distributed consensus mechanism enables the system to make correct decisions even when some nodes fail or are compromised, thus improving overall reliability.

[0045] Device Example 1 According to embodiments of the present invention, a multi-stage security verification device decouples payment results from user login status is provided. Figure 8 This is a schematic diagram of a multi-stage security verification device for decoupling payment results from user login state, as described in an embodiment of the present invention. Figure 8 As shown, the multi-stage security verification device decoupling payment result from user login state according to an embodiment of the present invention specifically includes: The payment result processing module 80 is used to parse the callback data and perform decoupled storage of the payment result after the user initiates a payment request and the payment is successful, in response to the payment callback notification sent by the payment platform through the merchant server. The authorization management module 82 is used to determine whether it is a payment on behalf scenario. If it is determined to be a payment on behalf scenario, the unique identifier of the payment user is added to the list of authorized operators for the order. The multi-source comparison and authorization verification engine 84 is used to receive the order fulfillment request initiated by the front end, query the payment result of the order, and obtain the current status of the order on the payment platform and the payment user identifier from the order query interface of the payment platform. It compares the unique identity identifier in the fulfillment request of the front end, the payment user identifier in the payment result, and the payment user identifier fed back by the payment platform, and dynamically determines whether the order is operated by the payer or a user authorized by the payer with the same identity based on the list of authorized operators.

[0046] In one embodiment of the present invention, the above-mentioned device specifically includes the following modules: Payment result processing module: Receives payment callbacks, extracts and stores openid_pay, openid_order, payment environment characteristics, etc.

[0047] State Management Module: Maintains the order state machine ("Payment in Progress", "Pending Fulfillment", "Fulfilled", "Payment Failed"), and controls the locking and releasing of sensitive operations.

[0048] Authorization Management Module: Manages the list of authorized operators and their operating permissions for orders.

[0049] Multi-source comparison and authorization verification engine: performs three-factor consistency comparison and authorization verification logic.

[0050] Trust assessment module: Calculates dynamic trust values ​​and outputs tiered decisions.

[0051] Consensus Verification Module: Initiates distributed consensus verification in high-security scenarios.

[0052] Decision execution module: Based on the verification and evaluation results, it allows or blocks the performance operation and triggers the corresponding process.

[0053] The embodiments of the present invention are device embodiments corresponding to the above method embodiments. The specific operation of each module can be understood with reference to the description of the method embodiments, and will not be repeated here.

[0054] Device Example 2 This invention provides an electronic device, such as... Figure 9 As shown, it includes: a memory 90, a processor 92, and a computer program stored in the memory 90 and executable on the processor 92, wherein the computer program, when executed by the processor 92, performs the steps as described in the method embodiment.

[0055] Device Example 3 This invention provides a computer-readable storage medium storing an information transmission implementation program, which, when executed by a processor 92, performs the steps described in the method embodiment.

[0056] The computer-readable storage media described in this embodiment include, but are not limited to, ROM, RAM, disk, or optical disk.

[0057] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-stage security verification method decoupling payment result from user login state, characterized in that, include: Step 1: After the user initiates a payment request and the payment is successful, the merchant server responds to the payment callback notification sent by the payment platform, parses the callback data, and performs decoupled storage of the payment result. Step 2: Determine if it is a payment on behalf scenario. If it is, add the unique identifier of the payment user to the list of authorized operators for this order. Step 3: Receive the order fulfillment request initiated by the front end, query the payment result of the order, and obtain the current status of the order on the payment platform and the payment user identifier from the order query interface of the payment platform. Compare the unique identity identifier in the fulfillment request from the front end, the payment user identifier in the payment result, and the payment user identifier fed back by the payment platform. Based on the authorized operator list, dynamically determine whether the order was operated by the payer or a user authorized by the payer with the same identity.

2. The method according to claim 1, characterized in that, After a user initiates a payment request and the payment is successful, the merchant server responds to the payment callback notification sent by the payment platform, parses the callback data, and performs decoupled storage of the payment result, specifically including: When a user initiates a payment request, the backend creates an order and sets the order status to "paying". Lock down all operations involving funds or sensitive data; Call the payment platform's order placement interface and pass in the current login status, i.e., the login status openid_order when initiating the payment; After successful payment, the merchant server receives a payment callback notification asynchronously sent by the payment platform; The merchant server parses the callback data, extracts the payment user's unique identifier openid_pay, payment time, environmental characteristics at the time of payment, and the user identifier openid_order at the time of order placement, and stores them in the order database. The order status is updated to "pending fulfillment", and all operations involving funds or sensitive data are unlocked.

3. The method according to claim 1, characterized in that, Determine if it is a payment on behalf scenario. If it is, add the payment user's unique identifier to the authorized operator list for this order, specifically including: Automatically determine whether openid_pay is equal to openid_order. If openid_pay is not equal to openid_order, it is determined to be a payment on behalf of another person. If openid_pay is equal to openid_order, it is determined to be a payment made by the person themselves. The openid_pay is automatically added to the authorized operator list authorized_openids for this order. Alternatively, the payer can manually add other delegates to the authorized operator list through the user-guided interface and set the operation permissions for each delegate. The authorized operator list is then persistently stored.

4. The method according to claim 1, characterized in that, Step 3 specifically includes: Receive a fulfillment request initiated by the front end, wherein the fulfillment request carries the openid_req of the current login state, the order number and the current environment characteristics; Based on the order number, retrieve the openid_pay, openid_order, authorized_openids, payment time, and payment environment characteristics of the order from the database in China; In real time, call the payment platform's order query interface to obtain the current status of the order on the payment platform and the payment user identifier openid_wx; Check if openid_req is equal to openid_pay and if openid_pay is equal to openid_wx. If they are, the operation is performed by the authorized person and the payment is allowed. If they are not, check if openid_req is in the authorized operator list authorized_openids and if openid_req is equal to openid_wx. If they are, the operation is performed by the authorized person and the authorizer is the actual payer, so the payment is allowed. If they are not, intercept the request, log the exception and trigger an alarm.

5. The method according to claim 1, characterized in that, The method further includes: Calculate the Trust value for the current request using Formula 1 or a machine learning model: Official 1; Where BaseScore is the basic trust score, Δt is the time difference between payment completion and the current request, and λ is the attenuation coefficient set according to the business requirements. The similarity between the current environmental characteristics and the payment environment characteristics; Based on the Trust value, a tiered decision is made: if Trust is greater than or equal to a first predetermined threshold, the verification is automatically performed; if Trust is greater than or equal to a second predetermined threshold but less than the first predetermined threshold, an enhanced verification process is triggered; if Trust is less than the second predetermined threshold, the verification is blocked and transferred to manual review, wherein the first predetermined threshold is greater than the second predetermined threshold.

6. The method according to claim 5, characterized in that, The enhanced verification process specifically includes: Trigger verification processes using SMS verification codes, fingerprints, and / or facial recognition.

7. The method according to claim 1, characterized in that, The method further includes: For high-value orders that meet the predetermined value rules or high-risk operations that meet the predetermined risk rules, a distributed consensus mechanism is activated: the predetermined key order information is stored simultaneously on multiple independent nodes, wherein the predetermined key order information includes: openid_pay, order amount, and order status hash value; the multiple independent nodes specifically include: a master database, a read-only slave database, and a blockchain evidence storage node; When a payment request is made, the payment openid is queried from all nodes. A predetermined algorithm is used for voting. Only when more than a predetermined number of nodes return a consistent result that matches the requested openid is the request allowed. Otherwise, an enhanced verification process is triggered or the request is blocked and transferred to manual review. The predetermined algorithm includes the Raft algorithm or the Byzantine fault tolerance algorithm.

8. A multi-stage security verification device decoupling payment result from user login state, characterized in that, include: The payment result processing module is used to respond to the payment callback notification sent by the payment platform through the merchant server after the user initiates a payment request and the payment is successful, parse the callback data, and perform decoupled storage of the payment result; The authorization management module is used to determine whether it is a payment on behalf scenario. If it is determined to be a payment on behalf scenario, the unique identifier of the payment user is added to the list of authorized operators for this order. The multi-source comparison and authorization verification engine is used to receive the order fulfillment request initiated by the front end, query the payment result of the order, and obtain the current status of the order on the payment platform and the payment user identifier from the order query interface of the payment platform. It compares the unique identity identifier in the fulfillment request of the front end, the payment user identifier in the payment result, and the payment user identifier fed back by the payment platform, and dynamically determines whether the order is operated by the payer or a user authorized by the payer with the same identity based on the list of authorized operators.

9. An electronic device, characterized in that, include: The memory, the processor, and the computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the multi-stage security verification method for decoupling payment results from user login state as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an implementation program for information transmission, which, when executed by a processor, implements the steps of the multi-stage security verification method for decoupling payment results from user login state as described in any one of claims 1 to 7.

Images