Transaction verification method, device and equipment, computer storage medium and program product

Abstract

The invention discloses a transaction verification method, device and equipment, a computer storage medium and a program product, and is applied to the field of transaction verification, and the method comprises the steps: receiving first to-be-verified information and payee identity authentication information sent by a payee of a to-be-verified transaction; generating an access link of the transaction under the condition that the identity authentication information of the payee is passed; sending the access link to a payee, so that the payee forwards the access link to a payer of the to-be-verified transaction through the target social application; the payee and the payer are mutual contacts in the target social application; receiving second to-be-verified information and payer identity authentication information sent by the payer; when the first to-be-verified information and the second to-be-verified information meet a preset condition, determining that the to-be-verified transaction is a normal transaction; and under the condition that the first to-be-verified information and the second to-be-verified information do not meet the preset condition, determining that the to-be-verified transaction is an abnormal transaction. The method can instantly start the verification process and improve the accuracy of the verification result.

Description

Technical Field

[0001] This application belongs to the field of transaction verification technology, and in particular relates to a transaction verification method, apparatus, equipment, computer storage medium and program product. Background Technology

[0002] Currently, the risk verification methods commonly used in online transactions mainly rely on post-transaction monitoring models. When the system detects a risk in a transaction, it typically takes measures such as freezing the account and conducts manual verification through methods such as SMS verification codes, telephone follow-ups, or requiring customers to submit paper supporting documents. These methods constitute the mainstream transaction verification methods currently available.

[0003] However, the aforementioned existing technical solutions have obvious drawbacks: First, their verification methods are relatively simple and fragile, for example, SMS verification codes may be intercepted, and manual review is inefficient; second, the existing process usually only inquires about one party to the transaction (such as the payee), lacking effective verification of the counterparty (payer), thus making it difficult to effectively prevent fraudulent activities such as impersonating others or forging transaction backgrounds. Summary of the Invention

[0004] This application provides a transaction verification method, apparatus, device, computer storage medium, and program product that can instantly initiate the verification process and improve the accuracy of the verification results.

[0005] In a first aspect, embodiments of this application provide a transaction verification method, executed by a transaction verification mini-program server, the method comprising: Receive the first verification information and the recipient's identity authentication information sent by the recipient of the transaction to be verified; the first verification information is obtained by the recipient by filling in the first verification interface displayed on the transaction verification mini-program client; the transaction verification mini-program is a mini-program embedded in the target social application. Once the recipient's identity verification information is approved, an access link for the transaction to be verified is generated. The access link is sent to the payee, who then forwards it to the payer of the transaction to be verified through the target social application. The payer then accesses the second verification interface through the access link and fills in the second verification information of the transaction to be verified on the second verification interface. The payee and the payer are contacts of each other in the target social application. Receive the second verification information and the payer's identity authentication information sent by the payer; If the payer's identity authentication information is passed and the first and second information to be verified meet the preset conditions, the transaction to be verified is determined to be a normal transaction. If the first and second pieces of information to be verified do not meet the preset conditions, the transaction to be verified is determined to be an abnormal transaction.

[0006] In some possible implementations, the method further includes, before receiving the second verification information and the payer's authentication information sent by the payer: Receive access requests from users for access links; Record the number of access requests received, authenticate the accessing user, and obtain the authentication result; If the number of requests is less than the preset number and the authentication result indicates that the user is the payer, a second verification interface is allowed to be displayed on the payer's transaction verification mini-program client. If the number of requests is less than the preset number and / or the authentication result indicates that the accessing user is not the payer, the second verification interface shall be prohibited from being displayed on the payer's transaction verification mini-program client.

[0007] In some possible implementations, the accessing user is authenticated, and the authentication result is obtained, including: Obtain the primary identity identifier of the accessing user's social application; The identity verification is successful if the first identity identifier of the social application matches the second identity identifier of the social application recorded by the transaction verification mini-program server, or if the second identity identifier of the social application is empty. Identity verification fails if the primary identity identifier of the social application does not match the secondary identity identifier of the social application recorded by the transaction verification mini-program server.

[0008] In some possible implementations, the accessing user is authenticated, and the authentication result is obtained, including: Extract a one-time verification token from the access link; If the record status of the one-time verification token is valid, obtain at least one verification association feature of the accessing user; The verification-related features are input into a preset verification algorithm to obtain a comprehensive verification result; Based on the comprehensive verification results, output the identity verification result.

[0009] In some possible implementations, the verification association features include the payer's IP address, request timestamp, and device fingerprint information. These features are input into a preset verification algorithm to obtain a comprehensive verification result, including: Based on the IP address, calculate its geographical deviation from the payee's IP address recorded when the one-time verification token was generated; Calculate the time interval between the request timestamp and the generation timestamp of the one-time verification token; Based on the device fingerprint information, calculate its matching degree with the payee device fingerprint information recorded when the one-time verification token is generated; The geographical deviation, time interval, and matching degree are compared with their respective preset thresholds, and the corresponding comparison results are obtained. If the comparison result meets the preset judgment conditions, the identity verification is successful. If the comparison result does not meet the preset judgment conditions, the identity verification fails.

[0010] In some possible implementations, the method may also include the following before retrieving the one-time verification token from the access link: Generate a unique verification task identifier that corresponds to this verification. The verification task identifier is encrypted based on a preset encryption factor to generate a one-time verification token; Generate an access link containing the one-time verification token.

[0011] In some possible implementations, the first information to be verified includes first transaction background information and / or a first questionnaire, and the second information to be verified includes a second transaction background information and / or a second questionnaire. Before the payer's identity authentication information is passed and the first and second information to be verified meet preset conditions, the method further includes: Verify whether the background information of the first transaction and the background information of the second transaction are consistent; And / or verify whether the answers to the first questionnaire match the first preset rule; And / or verify whether the answers to the second questionnaire match the second preset rule.

[0012] Among some possible implementations, the method also includes: Record the number of times the recipient forwards the access link; Once the preset number of forwards has been reached, the recipient will be prohibited from forwarding the access link any further.

[0013] Secondly, embodiments of this application provide a transaction verification mini-program server, the server comprising: The first information receiving module is used to receive the first verification information and the recipient's identity authentication information sent by the recipient of the transaction to be verified. The first verification information is obtained by the recipient by filling in the first verification interface displayed on the transaction verification mini-program client. The transaction verification mini-program is a mini-program embedded in the target social application. The link generation module is used to generate an access link for the transaction to be verified after the recipient's identity authentication information is passed. The link sending module is used to send an access link to the payee, so that the payee forwards it to the payer of the transaction to be verified through the target social application. The payer then enters the second verification interface through the access link and fills in the second verification information of the transaction to be verified on the second verification interface. The payee and the payer are contacts of each other in the target social application. The second information receiving module is used to receive the second information to be verified and the payer's identity authentication information sent by the payer. The normal determination module is used to determine that the transaction to be verified is a normal transaction when the payer's identity authentication information is passed and the first and second information to be verified meet preset conditions. The anomaly detection module is used to determine that the transaction to be verified is an abnormal transaction when the first and second information to be verified do not meet the preset conditions.

[0014] Thirdly, embodiments of this application provide an electronic device, the device comprising: a processor and a memory storing computer program instructions; the processor executing the computer program instructions implements the transaction verification method of any one of the above.

[0015] Fourthly, embodiments of this application provide a computer storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the transaction verification method described above is implemented.

[0016] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by the processor of an electronic device, enable the electronic device to perform any of the transaction verification methods described above.

[0017] The transaction verification method, apparatus, device, computer storage medium, and program product of this application, by embedding a transaction verification mini-program into a target social application, leverages the real-time interactive attributes of social applications to break through the limitations of traditional risk control's "post-event intervention." It initiates the verification process instantly during the transaction, achieving real-time risk control and effectively preventing the progression of abnormal transaction behavior. Secondly, it implements a two-way verification mechanism between the payee and payer, collecting the payee's information to be verified and identity authentication data while requiring the payer to complete information entry and identity verification. This overcomes the shortcomings of existing technologies that only perform one-way verification, ensuring that both parties acknowledge the authenticity of the transaction and fundamentally reducing the risk of fraud such as identity theft and falsified transaction backgrounds. Furthermore, by collecting information through a dedicated verification interface on the mini-program client, it replaces the traditional method of submitting paper materials, simplifying the verification process, shortening the verification cycle, improving transaction processing efficiency, and simultaneously reducing the manual review costs for banks and the operational costs for customers, significantly improving the user experience. Furthermore, by leveraging the contact relationships between the payee and payer in the target social application, the relevance and credibility of the verification entities can be strengthened, increasing the dimensions of transaction verification, improving the accuracy of verification results, and effectively reducing the risk of abnormal telecommunications transactions. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the structure of a transaction verification system provided in one embodiment of this application; Figure 2 This is a signaling diagram of a transaction verification method provided in another embodiment of this application; Figure 3 This is a flowchart illustrating a transaction verification method provided in yet another embodiment of this application; Figure 4 This is a flowchart illustrating a transaction verification method provided in yet another embodiment of this application; Figure 5 This is a flowchart illustrating a transaction verification method provided in yet another embodiment of this application; Figure 6 This is a schematic diagram of the structure of a transaction verification applet server provided in another embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0020] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0021] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0022] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0023] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0024] In online transaction scenarios, the widespread adoption of electronic payments has led to a continuous expansion in transaction volume and frequency. This has significantly increased the difficulty of verifying the identities and background authenticity of both parties involved in the transaction. Existing transaction risk verification methods have inherent limitations in their technical design, resulting in related technical problems. From a technical implementation perspective, existing solutions are based on one-way verification and post-transaction intervention. Their verification dimensions focus solely on the identity or document submission of a single transaction entity (such as the payee), failing to fully consider the two-way correlation of transaction behavior. The authenticity of a transaction depends on the consensus and background matching of both parties. Verifying only one party cannot form a complete verification loop, allowing fraudulent activities such as identity theft and falsifying transaction backgrounds to evade verification through "information asymmetry."

[0025] Meanwhile, existing verification methods suffer from an imbalance between security and efficiency: SMS verification codes rely on communication networks for transmission, lacking anti-interception and anti-forgery technical safeguards, and fail to incorporate multi-dimensional verification factors such as biometrics and social relationships; manual review relies on paper-based document processing and human judgment, limited by labor costs and review cycles, making it unsuitable for the real-time demands of online transactions, resulting in low review efficiency and susceptibility to misjudgments or omissions due to document forgery and subjective bias. Furthermore, existing solutions lack a real-time interactive verification mechanism between the transacting parties, resulting in a disconnect between the verification process and the transaction process. This prevents real-time verification of information consistency between the two parties during the transaction, allowing only passive intervention such as freezing accounts after a risk occurs, further exacerbating verification lag and the passivity of fraud prevention. Ultimately, this highlights technical problems such as the vulnerability of a single verification method, lack of counterparty verification, and poor fraud prevention effectiveness.

[0026] The transaction verification method in this application relies on a transaction verification mini-program embedded in the target social application. Leveraging the real-time interactive attributes of social applications, it breaks through the limitations of traditional risk control's "post-event intervention," initiating the verification process instantly during the transaction to achieve real-time risk control and effectively prevent abnormal transaction behavior. Secondly, it implements a two-way verification mechanism between the payee and payer, collecting the payee's information to be verified and identity authentication data while requiring the payer to complete information entry and identity verification. This overcomes the shortcomings of existing technologies that only perform one-way verification, ensuring that both parties acknowledge the authenticity of the transaction and fundamentally reducing the risk of fraud such as identity theft and falsified transaction backgrounds. Furthermore, information is collected through a dedicated verification interface on the mini-program client, replacing traditional paper material submissions, simplifying the verification process, shortening the verification cycle, improving transaction processing efficiency, and reducing bank manual review costs and customer operation costs, significantly improving user experience. In addition, by utilizing the contact relationships between the payee and payer in the target social application, the relevance and credibility of the verification subjects are strengthened, increasing the dimensions of transaction verification, improving the accuracy of verification results, and effectively reducing the risk of abnormal telecommunications transactions.

[0027] To address the problems of the prior art, embodiments of this application provide a transaction verification method, apparatus, device, computer storage medium, and computer program product. The transaction verification system provided in this application embodiment will be described first below.

[0028] Figure 1 A schematic diagram of the structure of a transaction verification system provided in one embodiment of this application is shown. Figure 1 As shown, the system includes a transaction verification mini-program server 101, a payee 102, a payer 103, and a target social application 104.

[0029] As an example, the transaction verification mini-program server 101 can be the core processing unit supporting the entire transaction verification process, responsible for receiving, storing, and verifying various verification data, generating access links, managing the verification process, and determining the transaction result.

[0030] As an example, payer 102 can refer to the entity receiving funds in the transaction to be verified, which may include individual customers and corporate customers.

[0031] As an example, payer 103 can refer to the party transferring funds in the transaction to be verified. They are contacts with the payee in the target social application and are an important entity for verifying the authenticity of the transaction.

[0032] As an example, target social application 104 can refer to an application platform with a mature social relationship chain and user base, in which a transaction verification mini-program is embedded, which can leverage its social attributes to achieve convenient interaction and information transmission between the two parties in the transaction.

[0033] Figure 2 A flowchart illustrating a transaction verification method provided in one embodiment of this application is shown. Figure 2 As shown, the method includes the following steps: S201, the payee fills in the first verification information on the first verification interface displayed on the transaction verification mini-program client.

[0034] As an example, a transaction verification mini-program client can be a terminal application embedded in a target social application, providing an interactive entry point for verification operations for both the payee and the payer, and integrating functions such as information filling, identity authentication, link receiving and forwarding.

[0035] As an example, the first verification interface can be an information entry interface specifically set up for the payee in the transaction verification mini-program client. The interface includes fields for filling in the transaction background and adapts to the information collection requirements of transaction verification.

[0036] As an example, the first piece of information to be verified can be the basis for determining the authenticity of a transaction. Specifically, it can be background information on the transaction, including key content such as the purpose of the transaction.

[0037] Specifically, as an example, after a transaction triggers the risk control model, the payee can log in to a transaction verification mini-program client embedded in the target social application. The client automatically displays the first verification interface. On this interface, the payee truthfully fills in the transaction background information according to the actual transaction situation, ensuring that the information is complete and accurate, providing a reliable basis for subsequent information comparison with the payer.

[0038] S202, The transaction verification mini-program server receives the first verification information and the recipient's identity authentication information sent by the recipient of the transaction to be verified; the transaction verification mini-program is a mini-program embedded in the target social application.

[0039] As an example, transactions pending verification can refer to online transactions that require two-way verification to confirm their security after triggering the financial risk control model. Such transactions have potential risks and need to be further verified for authenticity and legality.

[0040] As an example, recipient identity authentication information can refer to key information used to confirm the recipient's true identity. The core of this information includes facial recognition data, which is an important basis for ensuring the authenticity of the identity of the verification subject.

[0041] Specifically, as an example, after the payee completes the first piece of information to be verified, they simultaneously submit their own identity authentication information. The transaction verification mini-program client encrypts and transmits the first piece of information to be verified and the payee's identity authentication information to the transaction verification mini-program server. The server receives the data through a preset communication protocol, and an encryption mechanism is used during the reception process to ensure the security of data transmission and prevent information leakage or tampering.

[0042] S203, if the recipient's identity verification information is successful, the transaction verification mini-program server generates an access link for the transaction to be verified.

[0043] As an example, the recipient's identity authentication information can be obtained by comparing the received recipient's identity authentication information with the recipient's pre-registered identity information to confirm that the operator is the recipient and that the identity information is authentic and valid.

[0044] As an example, the access link can be a unique network access address generated by the server specifically for the current transaction to be verified. It corresponds one-to-one with the transaction to be verified, has unique identification, and is used to connect the verification process between the payee and the payer.

[0045] Specifically, as an example, after receiving the recipient's identity authentication information, the transaction verification mini-program server initiates an identity verification process, comparing the identity authentication information submitted by the recipient with the pre-registered information. Upon successful verification, the server generates an access link based on key information such as the unique identifier of the transaction to be verified and the recipient's identity identifier, following a preset algorithm. A secure coding mechanism is incorporated into the generation process to enhance the link's anti-forgery capabilities.

[0046] S204, the transaction verification mini-program server will send the access link to the payee.

[0047] Specifically, as an example, after the server generates the access link, it pushes the access link to the recipient's transaction verification mini-program client through the integration channel between the transaction verification mini-program and the target social application. The server synchronously records the link sending status, and if a sending failure occurs, it initiates a retry mechanism to ensure that the recipient receives the link in a timely manner and to ensure the smooth progress of the verification process.

[0048] S205, the payee forwards an access link to the payer of the transaction to be verified through the target social application.

[0049] Specifically, as an example, after receiving the access link through the transaction verification mini-program client, the payee directly forwards the access link to the corresponding payer using the communication function of the target social application. The server controls the link forwarding behavior, restricting the link to be sent directly to friends through the target social application and disallowing secondary forwarding, ensuring that the link is not illegally spread or abused.

[0050] S206, the payer accesses the second verification interface via a link and fills in the second verification information of the transaction to be verified on the second verification interface; the payee and the payer are contacts of each other in the target social application.

[0051] As an example, the second verification interface can be an information entry and confirmation interface specifically set up for the payer in the transaction verification mini-program client, including functional modules such as transaction background confirmation, questionnaire response, and electronic signature.

[0052] As an example, the second information to be verified may include the payer's confirmation of the transaction background, questionnaire responses, and electronic signatures, where the questionnaire responses cover key information related to the authenticity of the transaction, such as whether the payee knows the payee.

[0053] Specifically, as an example, after receiving an access link forwarded by the payee through the target social application, the payer can click the link to be directly redirected to the second verification interface of the transaction verification mini-program client through the built-in access function of the target social application. On this interface, the payer first confirms whether the transaction background information is consistent with the transaction situation they are aware of, then truthfully answers the questionnaire questions, completes the electronic signature operation, and submits the second information to be verified.

[0054] S207, The transaction verification mini-program server receives the second verification information and the payer's identity authentication information sent by the payer.

[0055] As an example, payer identity authentication information can be used to verify the payer's true identity. The core of this information includes real-name authentication information and facial recognition data, which is an important basis for ensuring the authenticity of the payer's identity.

[0056] Specifically, as an example, after the payer completes the second verification information and electronic signature, they simultaneously submit their personal identity authentication information. The transaction verification mini-program client encrypts and transmits the second verification information and the payer's identity authentication information to the transaction verification mini-program server. The server receives the data through an encrypted communication protocol, ensuring the security and integrity of the data transmission process.

[0057] S208, the transaction verification mini-program server determines that the transaction to be verified is a normal transaction if the payer's identity authentication information is passed and the first and second information to be verified meet the preset conditions.

[0058] As an example, the payer's identity authentication information can be obtained by comparing the received payer's identity authentication information with the payer's pre-registered identity information to confirm that the operator is the payer and that the identity information is authentic and valid.

[0059] As an example, preset conditions can refer to preset information matching rules in the server, including the consistency between the first and second information to be verified, the matching degree between the questionnaire response and the preset rules, and other judgment criteria.

[0060] As an example, a normal transaction can refer to a transaction that has been verified by both parties, confirming that the identities of both parties are genuine, the transaction background is consistent, and there is no risk of fraud.

[0061] Specifically, as an example, after receiving the payer's identity authentication information, the server verifies it to confirm the authenticity and validity of the identity. Subsequently, the server compares the first piece of information to be verified submitted by the payee with the second piece of information to be verified submitted by the payer, verifying their consistency and checking whether the questionnaire responses comply with preset rules. If the payer's identity authentication is successful and both types of information meet the preset conditions, the server determines the transaction to be verified as a normal transaction, automatically lifts account control, allows the transaction to proceed, and notifies both the payer and payee via SMS or other channels.

[0062] S209, if the transaction verification mini-program server determines that the transaction to be verified is an abnormal transaction if the first and second information to be verified do not meet the preset conditions.

[0063] As an example, an abnormal transaction can refer to a transaction where, after two-way verification, the information submitted by the two parties is inconsistent or does not comply with preset rules, and there is a risk of fraud such as identity forgery or false transaction background.

[0064] Specifically, as an example, after comparing and verifying the first and second pieces of information to be verified, if the server finds that neither type of information meets the preset conditions, the transaction to be verified is determined to be an abnormal transaction regardless of whether the payer's identity authentication is successful. The server maintains control over the relevant accounts, does not allow the transaction to proceed, and informs both the payer and payee of the verification results through SMS or other channels, providing a basis for subsequent risk management.

[0065] The transaction verification method in this application, by embedding a transaction verification mini-program within the target social application, leverages the real-time interactive attributes of social applications to break through the limitations of traditional risk control's "post-event intervention." It initiates the verification process instantly during the transaction, achieving real-time risk control and effectively preventing the progression of abnormal transactions. Secondly, it implements a two-way verification mechanism between the payee and payer, collecting the payee's information to be verified and identity authentication data while requiring the payer to complete information entry and identity verification. This overcomes the shortcomings of existing technologies that only perform one-way verification, ensuring that both parties acknowledge the authenticity of the transaction and fundamentally reducing the risk of fraud such as identity theft and falsified transaction backgrounds. Furthermore, information is collected through a dedicated verification interface on the mini-program client, replacing traditional paper material submissions, simplifying the verification process, shortening the verification cycle, improving transaction processing efficiency, and reducing both bank manual review costs and customer operational costs, significantly improving user experience. In addition, by utilizing the contact relationships between the payee and payer in the target social application, the relevance and credibility of the verification subjects are strengthened, increasing the dimensions of transaction verification, improving the accuracy of verification results, and effectively reducing the risk of abnormal telecommunications transactions.

[0066] As another implementation of this application, in order to enhance the security of the verification process, such as Figure 3 As shown, prior to S207, the method may further include the following steps: S301, The transaction verification mini-program server receives an access request from a user for an access link.

[0067] As an example, the user who clicks the access link and initiates the access operation could be the payer of the transaction to be verified or other unrelated persons.

[0068] As an example, an access request can refer to a request signal sent by a user to the transaction verification mini-program server after clicking the access link, requesting access to the second verification interface, and containing relevant access association information of the user.

[0069] Specifically, as an example, after a user clicks on an access link forwarded by the payment recipient, the transaction verification mini-program client will automatically send an access request to the transaction verification mini-program server. This request carries the user's basic access data. The transaction verification mini-program server receives this access request in real time through a preset communication receiving mechanism, providing a data foundation for subsequent access count statistics and identity verification.

[0070] S302, the transaction verification mini-program server records the number of access requests received, verifies the identity of the accessing user, and obtains the identity verification result.

[0071] As an example, the number of access requests can refer to the cumulative number of all access requests received by the transaction verification mini-program server for that access link from the time the access link is generated until the current time.

[0072] As an example, identity verification can refer to the process by which the transaction verification mini-program server verifies the relevant characteristic information of the accessing user to confirm whether they are the payer corresponding to the transaction to be verified.

[0073] As an example, authentication result can refer to the conclusion reached after authentication, including a pass result if the accessing user is the payer and a fail result if the accessing user is not the payer.

[0074] Specifically, as one implementation of S302, S302 also includes the following steps: The transaction verification mini-program server obtains the first identity identifier of the accessing user from their social application. The identity verification is successful if the first identity identifier of the social application matches the second identity identifier of the social application recorded by the transaction verification mini-program server, or if the second identity identifier of the social application is empty. The transaction verification mini-program server failed to verify identity if the primary identity identifier of the social application did not match the secondary identity identifier of the social application recorded by the transaction verification mini-program server.

[0075] As an example, the primary identity identifier of a social application can be a unique identifier for the user within the target social application. This identifier is assigned by the target social application to distinguish different user identities and is the core basis for confirming the user's identity within the social application.

[0076] As an example, the second identity identifier of a social application can be a unique identifier of the payer in the target social application that is pre-recorded by the transaction verification mini-program server and corresponds to the transaction to be verified. This identifier is used to compare with the first social application identity identifier of the accessing user to confirm whether the accessing user is the target payer.

[0077] Specifically, as an example, when a user clicks on an access link forwarded by the recipient through the target social application, the access response mechanism of the transaction verification mini-program is triggered. The transaction verification mini-program server, through its interface with the target social application, automatically obtains the user's primary social application identity identifier within that application. This acquisition process relies on the target social application's user authentication system to ensure that the obtained identity identifier is authentic and valid, and corresponds one-to-one with the user's actual social application account, providing accurate foundational data for subsequent identity verification.

[0078] Specifically, as an example, after the transaction verification mini-program server obtains the first social application identity identifier, it retrieves the related data of the transaction to be verified stored in the backend and extracts the recorded second social application identity identifier. Then, it initiates an identity comparison process, verifying the consistency between the first social application identity identifier and the second social application identity identifier. If the two match completely, it means the accessing user is the payer corresponding to the transaction to be verified, and the server determines that the identity verification is successful. If the second social application identity identifier is empty, meaning the server has not pre-recorded the social application identity identifier of the corresponding payer, the accessing user's identity is assumed to meet the preliminary verification requirements, and the identity verification is also determined to be successful, ensuring the smooth progress of the verification process in reasonable scenarios.

[0079] Specifically, as an example, after the transaction verification mini-program server compares the first social application identity identifier with the second social application identity identifier, if a discrepancy is found—that is, the accessing user's social application identity identifier does not correspond to the payer's social application identity identifier recorded by the server—it indicates that the accessing user is not the target payer of the transaction to be verified. At this point, the server determines that identity verification has failed and refuses to display the second verification interface to the accessing user. This prevents unauthorized personnel from interfering with the verification process or forging verification information, ensuring the uniqueness and authenticity of the verification subject, strengthening the security control of access links, and aligning with the technical design intent of setting restrictions on the forwarding of social application sharing links to prevent link abuse.

[0080] The transaction verification method in this application embodiment obtains the first identity identifier of the accessing user's social application and compares it with the second identity identifier of the social application recorded by the server. It directly utilizes the user identity system of the target social application, eliminating the need to build a complex additional identity authentication system, simplifying the verification process and improving the efficiency of identity verification. Simultaneously, the social application identity identifier possesses uniqueness and stability, accurately distinguishing different users and ensuring the accuracy of the identity verification results, effectively preventing non-target payers from obtaining verification permissions through false identities. For scenarios where the second identity identifier of the social application is empty, reasonable access rules are set to ensure the smooth progress of the verification process in special scenarios, balancing security and practicality. This technical solution further refines the identity verification logic of the accessing user, providing an efficient and accurate implementation path for the identity verification mechanism of claim 2, and strengthening the security of the verification process.

[0081] As another implementation of this application, the following steps may be included before S302: Generate a unique verification task identifier that corresponds to this verification. The verification task identifier is encrypted based on a preset encryption factor to generate a one-time verification token; Generate an access link containing the one-time verification token.

[0082] As an example, the verification task identifier can be a unique identifier code assigned exclusively to a single transaction to be verified. It has global uniqueness and is used to associate all data information in this verification process, including the verification information of the payee and payer, access links, one-time verification tokens, etc. It is the core associated credential that runs through the entire verification process.

[0083] As an example, this verification can refer to the complete two-way verification process initiated after a transaction triggers the risk control model, which covers a series of operations such as filling in the payee's information, identity authentication, generating access links, and verifying the payer.

[0084] As an example, the preset encryption factor can be a key parameter pre-configured in the transaction verification mini-program server for encryption calculation. It may include server-specific keys, dynamic time factors, system-randomly generated keys, etc. It has confidentiality and stability, and is used to improve the security of the encrypted token and prevent it from being cracked.

[0085] As an example, a one-time verification token can be an encrypted string obtained by processing the verification task identifier through an encryption algorithm. It is only valid in this verification process and is used to verify the legality and uniqueness of the access link, preventing the link from being tampered with or abused.

[0086] As an example, encryption can refer to the process of using a preset encryption algorithm and a preset encryption factor to process the verification task identifier and convert it into a string that cannot be directly interpreted. The purpose is to ensure the security of the verification task identifier and prevent it from being illegally obtained or tampered with.

[0087] As an example, an access link containing the token can refer to a complete access address formed by embedding a one-time verification token in the underlying network address. The one-time verification token serves as the core verification part of the link and is used by the server to verify the legitimacy of the access request.

[0088] Specifically, as an example, when a transaction triggers the risk control model and initiates the WeChat verification process, the transaction verification mini-program server starts an identifier generation mechanism for the transaction to be verified. The server combines unique transaction association information such as the transaction serial number, transaction timestamp, and payee / payer account identifiers of the transaction to be verified, and generates a verification task identifier using a preset encoding algorithm. During the generation process, it ensures that this identifier is unique and does not overlap with the identifiers of any other verification task, achieving one unique identifier for each verification. This provides a foundation for subsequent encryption, link generation, and data association and traceability in the verification process.

[0089] Specifically, as an example, after the transaction verification mini-program server generates a verification task identifier, it retrieves a preset encryption factor and uses an encryption algorithm that conforms to financial security standards to encrypt the verification task identifier. During the encryption process, the verification task identifier is combined with the preset encryption factor to ensure that the encrypted result is unique and unbreakable. After encryption, a one-time verification token is generated. This token corresponds one-to-one with the verification task identifier and can only be used for access link verification in this verification process. It expires after one use or after the expiration date, which meets the technical design requirements for access link security control.

[0090] Specifically, as an example, after the transaction verification mini-program server generates a one-time verification token, it initiates the access link generation process. The server first determines the basic network access address, which points to the access point to the second verification interface of the transaction verification mini-program. Then, the one-time verification token is embedded in this basic address, forming a complete access link. The generated access link retains the functionality to access the second verification interface while also binding access permissions through the built-in one-time verification token. This link will subsequently be sent to the recipient, who will then forward it to the payer through the target social application. The server will also implement restrictions such as link expiration control and prohibition of secondary forwarding to further enhance the security of the verification process and prevent link abuse.

[0091] The transaction verification method in this application generates a unique verification task identifier corresponding to each verification, ensuring that the verification process for each transaction is independent and facilitating data association and traceability. The verification task identifier is encrypted using a preset encryption factor to generate a one-time verification token, effectively preventing the verification task identifier from being illegally obtained or tampered with, thus ensuring the token's security. The one-time verification token is embedded in the access link, giving the access link exclusive verification attributes. The server can quickly identify the legitimacy of the access request by extracting the token, improving the efficiency of link verification. This technical solution provides crucial pre-support for the identity verification mechanism of claim 4. Through encryption processing and exclusive identifier design, it strengthens the security of the access link and verification token, laying a secure foundation for subsequent identity verification processes.

[0092] As another implementation of S302, S302 also includes the following steps: The transaction verification mini-program server extracts a one-time verification token from the access link; If the record status of the one-time verification token is valid, the transaction verification mini-program server obtains at least one verification association feature of the accessing user; The transaction verification mini-program server inputs the verification-related features into the preset verification algorithm to obtain a comprehensive verification result; The transaction verification mini-program server outputs the identity verification result based on the comprehensive verification results.

[0093] As an example, a one-time verification token can be an encrypted string generated by the transaction verification mini-program server based on a unique verification task identifier for this verification, combined with a preset encryption factor. It has uniqueness and timeliness, and is only used to verify the legitimacy of the access link in this transaction verification process to prevent the link from being tampered with or abused.

[0094] As an example, the record status of a one-time verification token can be the record information stored in the transaction verification mini-program server, which is used to identify whether the one-time verification token is in an available state, including two states: valid and invalid. In the valid state, the token has not expired, has not been used, and has not been tampered with.

[0095] As an example, verification association features can be information that reflects the identity and access behavior characteristics of the accessing user, used to assist in verifying whether the accessing user is the target payer of the transaction to be verified, including the accessing user's IP address, request timestamp, device fingerprint information, etc.

[0096] As an example, the preset verification algorithm can be a computational model pre-configured in the transaction verification mini-program server, used to analyze and verify related features and determine the legitimacy of the accessing user's identity. This algorithm combines the security requirements of transaction verification with logic such as feature comparison and threshold determination to ensure the accuracy of identity verification.

[0097] As an example, the comprehensive verification result can be a judgment result reflecting the degree of matching between the accessing user's identity and the target payer after inputting the verification-related features into a preset verification algorithm, providing the core basis for the output of the final identity verification result.

[0098] Specifically, as an example, when a user clicks on an access link forwarded by the payment recipient, the transaction verification mini-program server receives the access request and immediately initiates the link parsing process. The server uses a preset parsing algorithm to extract a built-in one-time verification token from specific fields in the access link. The extraction process strictly follows the encoding rules used when the link was generated, ensuring accurate separation of the one-time verification token from the basic access address. This provides the core basis for subsequent token validity verification and identity authentication, meeting the technical design requirements for secure access link control.

[0099] Specifically, as an example, after the transaction verification mini-program server retrieves the one-time verification token, it calls the token management data stored in the backend to query the record status corresponding to the one-time verification token. The server verifies whether the token is within the preset validity period, whether it has been reused, and whether it has been tampered with. If the above conditions are met, the token record status is determined to be valid. Under the premise that the token status is valid, the server obtains at least one verification-related feature of the accessing user through the interface linkage with the target social application and access terminal, ensuring that the obtained feature information is true and complete, and providing data support for subsequent comprehensive verification.

[0100] Specifically, as an example, after the transaction verification mini-program server obtains the verification-related features, it standardizes all feature data according to a preset format to ensure that the data meets the input requirements of the verification algorithm. Subsequently, the server inputs the standardized verification-related features into the preset verification algorithm, which performs multi-dimensional analysis and calculations on each feature. For example, it calculates the geographical deviation between the IP address and the payee's IP address, the time interval between the request timestamp and the token generation timestamp, and the matching degree between the device fingerprint information and the payee's device fingerprint. Through a comprehensive evaluation of the analysis results of each feature, the algorithm outputs a comprehensive verification result, achieving a preliminary determination of the accessing user's identity.

[0101] Specifically, as an example, after receiving the comprehensive verification result output by the preset verification algorithm, the transaction verification mini-program server interprets the comprehensive verification result according to preset judgment rules. If the comprehensive verification result shows that all verification-related features meet the relevant feature requirements of the target payer, such as geographical deviation within a preset reasonable range, time interval not exceeding a threshold, and device fingerprint matching degree meeting the standard, the server determines that the identity verification is successful and allows the user to enter the second verification interface to complete subsequent operations; if the comprehensive verification result shows that there is a feature mismatch, the server determines that the identity verification is unsuccessful, refuses to display the second verification interface, and prevents unauthorized personnel from interfering with the verification process. This operation, through multi-dimensional feature comprehensive verification, further enhances the accuracy and security of identity verification, aligning with the core of the invention of two-way verification and link security control.

[0102] The transaction verification method in this application provides an alternative identity verification scheme based on a one-time verification token and verification-related features, offering multiple technical advantages. First, the one-time verification token, as an encrypted and exclusive identifier, is used only in the current verification process, effectively preventing token tampering or reuse and enhancing identity verification security. Second, by acquiring the verification-related features of the accessing user and inputting them into a preset verification algorithm, multi-dimensional identity verification is achieved, overcoming the limitations of single-identity identifier comparison and improving the comprehensiveness and accuracy of identity verification. Third, feature collection and verification are only initiated when the one-time verification token record is valid, ensuring the compliance and timeliness of the verification process and avoiding wasted system resources from invalid verification operations. This technical solution provides a more flexible and secure implementation method for identity verification, allowing for the selection of an appropriate verification path based on the actual application scenario, further enhancing the adaptability and security of the transaction verification system.

[0103] The verification association features include the payer's IP address, request timestamp, and device fingerprint information. As one way to input the verification association features into a preset verification algorithm to obtain a comprehensive verification result, this step may also include the following steps: The transaction verification mini-program server calculates the geographical deviation between the IP address and the payee's IP address recorded when the one-time verification token is generated; The transaction verification mini-program server calculates the time interval between the request timestamp and the generation timestamp of the one-time verification token based on the request timestamp. The transaction verification mini-program server calculates the matching degree between the device fingerprint information and the recipient's device fingerprint information recorded when the one-time verification token is generated; The transaction verification mini-program server compares the geographical deviation, time interval, and matching degree with the corresponding preset thresholds and obtains the corresponding comparison results. The transaction verification mini-program server passes identity verification if the comparison result meets the preset judgment conditions. The transaction verification mini-program server failed to verify identity if the comparison result did not meet the preset judgment conditions.

[0104] As an example, an IP address can refer to the Internet Protocol address of the network used when a user initiates an access request. It can reflect the geographical location of the user's network access and is an important component of the verification association characteristics.

[0105] As an example, a one-time verification token can be an encrypted string generated by the transaction verification mini-program server based on a unique verification task identifier for this verification, combined with a preset encryption factor, and used to verify the legitimacy of accessing the link.

[0106] As an example, the payee's IP address can refer to the Internet Protocol address corresponding to the payee's operating terminal when the one-time verification token is generated. This address is recorded and stored by the server in real time and used as a comparison benchmark for calculating geographical deviation.

[0107] As an example, geographic bias can refer to the spatial distance difference between the geographic location corresponding to the IP address of the accessing user and the geographic location corresponding to the IP address of the payee, and is used to determine the reasonableness of the geographic association between the accessing user and the payee.

[0108] Specifically, as an example, after the transaction verification mini-program server obtains the IP address of the accessing user, it retrieves the relevant verification data stored in the backend and extracts the payee's IP address recorded when the one-time verification token was generated. Using a preset geolocation algorithm, it analyzes the specific geographical coordinates corresponding to the accessing user's IP address and the payee's IP address. Based on these coordinates, a geographical distance calculation model is used to calculate the spatial distance between the two locations. This distance is the geographical deviation, providing a geographical dimension for subsequent identity verification, aligning with the technical design intention of multi-dimensional verification to enhance security.

[0109] As an example, a request timestamp can refer to the data recorded by the transaction verification mini-program server at the current time point when a user clicks the access link to initiate an access request. It is presented in a specific time format and reflects the time when the access request was initiated.

[0110] As an example, the generation timestamp of a one-time verification token can refer to the time point data recorded by the transaction verification mini-program server when the one-time verification token is generated, which is consistent with the request timestamp format and serves as the basis for calculating the time interval.

[0111] As an example, the time interval can refer to the time difference between the request timestamp and the one-time verification token generation timestamp, used to determine whether the access request was initiated within a reasonable time range, ensuring the timeliness of verification.

[0112] Specifically, as an example, the transaction verification mini-program server extracts the request timestamp corresponding to the access request and simultaneously retrieves the generation timestamp of the one-time verification token from the stored token association data. Following preset time calculation rules, the two timestamps are converted to a unified time unit, and the absolute difference between them is calculated; this difference is the time interval. Using this time interval, it determines whether the access request was initiated within the validity period of the access link, avoiding security risks caused by link expiration, thus meeting the technical requirements for setting the validity period of access links.

[0113] As an example, device fingerprint information refers to the unique identifier of the operating terminal used by the user. It is generated by combining the terminal's hardware parameters, system configuration and other feature data. It can uniquely distinguish different operating devices and is one of the core features of identity verification.

[0114] As an example, the fingerprint information of the receiving device can refer to the unique identification information corresponding to the receiving terminal when a one-time verification token is generated. This information is collected and stored by the server in real time and used as a comparison benchmark for calculating the device matching degree.

[0115] As an example, the matching degree can refer to the degree of overlap between the accessing user's device fingerprint information and the receiving party's device fingerprint information, presented as a percentage or a quantitative value, to determine the correlation between the device used by the accessing user and the device operated by the receiving party.

[0116] Specifically, as an example, after the transaction verification mini-program server obtains the device fingerprint information of the accessing user, it retrieves the recipient's device fingerprint information recorded when generating the one-time verification token. Using a preset feature comparison algorithm, it compares key features such as hardware parameters and system configurations in the two sets of device fingerprint information one by one, counting the number and weight of overlapping features. Based on the statistical results, a quantitative value of the degree of overlap between the two sets of information is calculated. This quantitative value is the matching degree, providing a device-level basis for identity verification and enhancing the security of the verification.

[0117] As an example, the preset threshold can refer to the benchmark values ​​pre-configured in the transaction verification mini-program server to determine whether the geographical deviation, time interval and matching degree meet the requirements. These include the geographical deviation threshold, time interval threshold and matching degree threshold, which are set according to the security requirements of transaction verification and the actual scenario.

[0118] As an example, the comparison result can refer to the judgment result of whether each dimension meets the requirements after comparing the geographical deviation, time interval, and matching degree with the corresponding preset thresholds, including two cases: meeting the threshold requirements and not meeting the threshold requirements.

[0119] Specifically, as an example, the transaction verification mini-program server retrieves preset geographical deviation thresholds, time interval thresholds, and matching degree thresholds. The calculated geographical deviation is compared with the geographical deviation threshold to determine if it is within the allowed range; the time interval is compared with the time interval threshold to determine if the access request was initiated within the valid time; and the matching degree is compared with the matching degree threshold to determine if the overlap of the device fingerprint information meets the standard. The comparison results for each dimension are recorded to form corresponding comparison results, providing a basis for subsequent comprehensive judgment of the identity verification result.

[0120] As an example, the preset judgment conditions can refer to the rules pre-set in the transaction verification mini-program server, which determine whether the identity verification is successful by combining various comparison results. These rules require that the geographical deviation and time interval meet the corresponding threshold requirements, and that the matching degree reaches the corresponding threshold standard, so as to ensure the rationality and security of the accessing user's identity.

[0121] Specifically, as an example, the transaction verification mini-program server aggregates comparison results from various dimensions and performs a comprehensive judgment based on preset criteria. If the geographical deviation is less than or equal to the geographical deviation threshold, the time interval is less than or equal to the time interval threshold, and the matching degree is greater than or equal to the matching degree threshold, meaning all comparison results meet the preset requirements, it indicates that the user's geographical location, access time, and device are all within a reasonable range and have a reasonable connection with the payee. At this point, the server determines that the identity verification is successful, ensuring the smooth progress of the verification process and aligning with the core technologies of two-way verification and security control.

[0122] Specifically, as an example, after comprehensively analyzing the comparison results, if the transaction verification mini-program server detects any of the following: geographical deviation exceeding the geographical deviation threshold, time interval exceeding the time interval threshold, or matching degree falling below the matching degree threshold, it indicates that the user's geographical location, access time, or device is abnormal and lacks a reasonable connection with the payee, posing a risk of non-target payers interfering in the verification process. In this case, the server determines that identity verification has failed and refuses to display the second verification interface to prevent link abuse or forged verification information, further strengthening the security control of the access link and reducing the risk of abnormal telecommunications transactions.

[0123] The transaction verification method in this application calculates the geographical deviation between the accessing user's IP address and the receiving party's IP address to determine the reasonableness of the geographical association between the accessing user and the receiving party, effectively identifying the risk of unauthorized access from other locations. It calculates the time interval between the request timestamp and the token generation timestamp to ensure that the access request is initiated within a reasonable validity period, meeting the requirements for timeliness control of access links. It calculates the matching degree of device fingerprint information to verify the association between the accessing user's device and the receiving party's operating device, further eliminating the possibility of access by non-target entities. By comparing the results of the above three dimensions with corresponding preset thresholds, a multi-dimensional comprehensive judgment is achieved, significantly improving the accuracy of identity verification and effectively reducing the risk of false positives and false negatives. This technical solution transforms abstract verification association features into specific calculable indicators, making the identity verification process more operable and scientific, and providing a solid guarantee for the security of transaction verification.

[0124] S303, If the number of requests is less than the preset number and the authentication result indicates that the user is the payer, the transaction verification mini-program server allows the display of a second verification interface on the payer's transaction verification mini-program client.

[0125] As an example, the preset number of requests can refer to the maximum number of access requests that can be initiated to the access link, which is pre-set in the transaction verification mini-program server. This threshold is set according to the security requirements of transaction verification and the actual scenario, and is used to limit the access frequency of the link.

[0126] As an example, the second verification interface can be an information entry and confirmation interface exclusively set up for the payer in the transaction verification mini-program client. It includes functional modules such as transaction background confirmation, questionnaire response, and electronic signature. The payer can only access it after passing the identity verification and meeting the access requirements.

[0127] Specifically, as an example, the transaction verification mini-program server compares the recorded number of access requests with the preset number of requests, and simultaneously checks the identity verification results. When the number of access requests is less than the preset number of requests, and the identity verification result clearly indicates that the accessing user is the payer corresponding to the transaction to be verified, the server determines that the accessing user has access rights, sends an interface display instruction to the payer's transaction verification mini-program client, allowing the second verification interface to be displayed on the client for the payer to perform subsequent information filling operations.

[0128] S304, If the number of requests is less than the preset number and / or the authentication result indicates that the accessing user is not the payer, the transaction verification mini-program server shall prohibit the display of the second verification interface on the payer's transaction verification mini-program client.

[0129] Specifically, as an example, after the transaction verification mini-program server completes the comparison of access request counts and identity verification, if the number of access requests is greater than or equal to the preset number of requests, or the identity verification result indicates that the accessing user is not the payer corresponding to the transaction to be verified, or both situations exist simultaneously, the server determines that the accessing user does not have access rights, sends an interface prohibition instruction to the transaction verification mini-program client, and refuses to display the second verification interface. At the same time, the server can record this illegal access behavior, providing data support for subsequent security risk tracing and ensuring the security of the verification process.

[0130] The transaction verification method in this application adds access request control for access links and user authentication mechanisms to further enhance the security and controllability of the verification process. On one hand, by recording the number of access requests and comparing it with a preset request count, repeated access to the link is restricted, preventing process disruption or information leakage caused by malicious multiple access attempts and reducing the risk of link abuse. On the other hand, by authenticating the accessing user, it ensures that only the payer of the transaction to be verified can obtain access to the second verification interface, preventing unauthorized personnel from interfering with the verification process or forging verification information, and ensuring the uniqueness and authenticity of the verification subject. This technical solution, through dual protection of access control and authentication, effectively solves the security risks of unrestricted link access and easy intervention by non-target subjects in existing verification methods, providing a pre-emptive guarantee for the accuracy of subsequent verification information and further improving the reliability of transaction risk prevention and control.

[0131] As another implementation of this application, in order to improve the accuracy of transaction authenticity determination, such as Figure 4 As shown, the first information to be verified includes first transaction background information and / or a first questionnaire, and the second information to be verified includes second transaction background information and / or a second questionnaire. Before S208, the method may further include the following steps: S401, the transaction verification mini-program server verifies whether the first transaction background information and the second transaction background information are consistent.

[0132] As an example, the first transaction background information can be the core information related to the transaction to be verified that the payee fills in on the first verification interface of the transaction verification mini-program. This information includes key content such as the purpose of the transaction and is used to reflect the real transaction scenario stated by the payee. It is one of the basic bases for determining the authenticity of the transaction.

[0133] As an example, the second transaction background information can be the core information related to the transaction to be verified that the payer confirms or supplements on the second verification interface of the transaction verification mini-program. It corresponds to the information dimension of the first transaction background information and is used to reflect the real transaction scenario known to the payer.

[0134] As an example, "verification consistency" can refer to the transaction verification mini-program server confirming, through comparison, that the first transaction background information and the second transaction background information are consistent and identical in their core content, and can mutually verify the authenticity of the transaction.

[0135] Specifically, as an example, after receiving the first transaction background information submitted by the payee and the second transaction background information submitted by the payer, the transaction verification mini-program server initiates an information comparison process. The server extracts core dimensions such as the purpose of the transaction and the relationship between the transaction parties from both types of information and verifies them one by one according to preset comparison rules. For example, if the payee states that the transaction purpose is a loan to a relative or friend, the server will check whether the second transaction background information submitted by the payer also clearly states that the transaction purpose is a loan to a relative or friend, ensuring that the core transaction scenario stated by both parties is consistent. Through this verification operation, it verifies whether the two parties have a unified understanding of the transaction background, effectively preventing fraudulent behavior of forging transaction backgrounds, which aligns with the core technology of two-way verification.

[0136] S402, The transaction verification mini-program server verifies whether the answers to the first questionnaire match the first preset rule.

[0137] As an example, the first questionnaire answer can be the response submitted by the payee after completing the questionnaire on the first verification interface of the transaction verification mini-program. The questionnaire questions are designed around core issues such as the authenticity of the transaction and the identity of the payee. The answer is an important reference for judging the transaction risk.

[0138] As an example, the first preset rule can be a set of rules pre-configured in the transaction verification mini-program server to determine whether the answers to the first questionnaire meet the security verification standards. The rules are set based on anti-fraud risk control requirements and clarify the compliance scope and valid judgment basis of the questionnaire answers.

[0139] As an example, matching can mean that the content of the first questionnaire answer fully complies with the requirements of the first preset rule, there is no statement that conflicts with the rule or exceeds the scope of compliance, and it can prove that the transaction-related information stated by the payee is reasonable.

[0140] Specifically, as an example, after the transaction verification mini-program server retrieves the answers to the first questionnaire submitted by the payee, it calls up the first preset rules stored in the database. According to the compliant answer requirements for each questionnaire question in the rules, the server compares the first questionnaire answers with the rules one by one to determine their fit. For example, for questionnaire questions involving the relationship between the payee and the payer, the first preset rule specifies that the valid answer range is reasonable relationships such as relatives, friends, and colleagues. The server will verify whether the payee's answer falls within this range. If the first questionnaire answers fully comply with all the requirements of the first preset rule, the two are considered a match; if there are answers that exceed the compliant range or conflict with the rules, a mismatch is determined, providing a basis for subsequent transaction risk assessment.

[0141] S403, the transaction verification mini-program server verifies whether the answers to the second questionnaire match the second preset rule.

[0142] As an example, the answers to the second questionnaire can be the responses submitted by the payer after completing the questionnaire on the second verification interface of the transaction verification mini-program. The questionnaire questions focus on key issues such as the relationship between the payer and the payee and the level of awareness of the transaction, which are directly related to the determination of the authenticity of the transaction.

[0143] As an example, the second preset rule can be a set of rules pre-configured in the transaction verification mini-program server to determine whether the answers to the second questionnaire meet the security verification standards. It complements the first preset rule and clarifies the compliance requirements and risk assessment boundaries of the questionnaire answers from the perspective of the payer.

[0144] Specifically, as an example, after the transaction verification mini-program server obtains the answers to the second questionnaire submitted by the payer, it retrieves the second preset rules stored in the backend. According to the rules' definition of valid answers for each questionnaire question, the server verifies each answer in the second questionnaire. For example, regarding the questionnaire question about whether the payee knows the recipient, the second preset rule specifies that the compliant answer is "yes." The server will verify whether the payer's response is "yes" to verify the existence of a genuine relationship between the two parties. Through this verification operation, the authenticity and rationality of the transaction are further verified from the payer's perspective, compensating for the lack of effective verification of the payer in existing technologies. Combined with the verification results of the first questionnaire answers, a multi-dimensional risk assessment basis is formed, improving the accuracy and security of transaction verification.

[0145] It should be noted that you can execute steps S402 or S403, or both. Executing only S402 or S403 allows for flexible adaptation based on the actual scenario, such as the transaction risk level and the risk attributes of the entity, focusing on a single dimension to quickly screen for risks. Executing only S402 can quickly identify risk points such as false statements by the payee and non-compliant transaction purposes without waiting for the payer's operation, improving the processing efficiency of transactions related to high-risk payees. Executing only S403 can directly identify fraud scenarios such as identity theft and unauthorized transactions by the payer based on their response regarding the level of awareness of the transaction and the relationship between the two parties, strengthening the payer's control at the payer level while reducing the impact of delays in the operation of a single entity on the process. The simultaneous execution of steps S402 and S403 allows for the construction of a two-way rule verification closed loop based on the answers to the questionnaires from both the payer and payee. This loop verifies the compliance of the payee's transactions through the first questionnaire's answers and verifies the authenticity of the payer's transactions through the second questionnaire's answers. This achieves full coverage of risk dimensions, avoids omissions caused by verification by a single entity, and the rule matching results of the answers from both parties can corroborate each other, significantly improving the accuracy and credibility of transaction authenticity determination. This effectively addresses complex fraud scenarios and fully aligns with the core invention concept of two-way verification.

[0146] The transaction verification method in this application verifies the consistency between the first and second transaction background information, ensuring that both parties have a unified understanding of the core transaction scenario. This effectively blocks fraudulent activities involving falsified transaction backgrounds, aligning with the core design concept of two-way verification. By verifying the matching degree between the answers to the first questionnaire and the first preset rule, and the answers to the second questionnaire and the second preset rule, the compliance and rationality of transaction-related information can be verified from both the payer and payee perspectives, further identifying transaction risk points. This technical solution makes the verification of transaction information more targeted and comprehensive, ensuring that the determination of preset conditions has a clear basis, significantly improving the accuracy of transaction authenticity determination, and effectively reducing the risk of abnormal telecommunications transactions.

[0147] As another implementation of this application, in order to further enhance the security of the transaction verification process, such as Figure 5 As shown, the method may further include the following steps: S501 records the number of times the recipient forwards the access link.

[0148] As an example, the number of forwards can refer to the cumulative number of times the recipient sends the access link outward through the target social application. This number directly reflects the spread of the access link and is a core statistical indicator for controlling link abuse.

[0149] Specifically, as an example, after the transaction verification mini-program server generates an access link and sends it to the recipient, it simultaneously initiates a forwarding count recording mechanism. When the recipient initiates a link forwarding operation through the target social application, the target social application will send a forwarding behavior trigger signal to the transaction verification mini-program server. After receiving this signal, the server retrieves the unique identifier corresponding to the access link and the associated recipient information, and updates and stores the forwarding count statistics of the access link in real time. Each time a valid forwarding behavior is detected, the forwarding count value increases accordingly, ensuring accurate monitoring of link forwarding and providing data support for subsequent forwarding restriction and control, which aligns with the technical design intention of preventing link abuse.

[0150] S502: If the number of forwards reaches the preset number, the recipient is prohibited from forwarding the access link any further.

[0151] As an example, the preset forwarding count can refer to the maximum number of times the recipient is allowed to forward the access link, which is pre-configured in the transaction verification mini-program server. This threshold is set based on the security requirements of transaction verification and aims to limit the scope of link propagation and prevent unauthorized personnel from obtaining the link.

[0152] As an example, prohibiting further forwarding can refer to the server using technical means to block the recipient from subsequently forwarding the access link, preventing the recipient from sending the link to other parties through the target social application. This is a key control measure to ensure link security.

[0153] Specifically, as an example, the transaction verification mini-program server monitors the number of times the access link is forwarded in real time. After each update, the current forwarding count is compared with the preset forwarding count. When the preset forwarding count is detected, the server immediately triggers a forwarding restriction mechanism. On one hand, a forwarding prohibition command is sent to the recipient's transaction verification mini-program client. After receiving the command, the client hides or disables the link forwarding function button, preventing the recipient from initiating new forwarding operations. On the other hand, the server locks the forwarding permission for the access link. Even if the recipient attempts to trigger forwarding through other means, the server will refuse to respond to the forwarding request and provide a forwarding failure message. Through this operation, the number of times the access link is forwarded is strictly limited, ensuring that the link can only be delivered to the target payer, preventing security risks caused by multiple forwardings of the link, and strengthening the security and controllability of the verification process.

[0154] The transaction verification method in this application, by recording the number of times the recipient forwards the link, can monitor the propagation of the access link in real time, preventing the link from getting out of control due to multiple forwards. When the number of forwards reaches a preset limit, further forwarding is prohibited, ensuring that the access link can only be delivered to the target payer, preventing unauthorized personnel from obtaining the link and attempting illegal access, and effectively avoiding the risk of link abuse. This technical solution, together with security mechanisms such as access link validity control and secondary forwarding restrictions, forms a comprehensive link security management system, further strengthening the security of the transaction verification process, ensuring that verification information is not illegally leaked or tampered with, and providing important support for the secure advancement of the entire transaction verification process.

[0155] Based on the transaction verification method provided in the above embodiments, this application also provides a specific implementation method for a transaction verification mini-program server. Please refer to the following embodiments.

[0156] First see Figure 6 The transaction verification applet server 60 provided in this application embodiment includes the following modules: The first information receiving module 601 is used to receive the first verification information and the identity authentication information of the payee of the transaction to be verified. The first verification information is obtained by the payee filling in the first verification interface displayed on the transaction verification mini-program client. The transaction verification mini-program is a mini-program embedded in the target social application. The link generation module 602 is used to generate an access link for the transaction to be verified when the recipient's identity authentication information is passed. The link sending module 603 is used to send an access link to the payee, so that the payee forwards it to the payer of the transaction to be verified through the target social application, thereby enabling the payer to enter the second verification interface through the access link and fill in the second verification information of the transaction to be verified on the second verification interface; the payee and the payer are contacts of each other in the target social application. The second information receiving module 604 is used to receive the second information to be verified and the payer's identity authentication information sent by the payer. The normal determination module 605 is used to determine that the transaction to be verified is a normal transaction when the payer's identity authentication information is passed and the first and second information to be verified meet preset conditions. The anomaly determination module 606 is used to determine that the transaction to be verified is an abnormal transaction when the first information to be verified and the second information to be verified do not meet the preset conditions.

[0157] In some embodiments, the transaction verification mini-program server 60 may further include the following modules: The request receiving module is used to receive the access request from the user for the access link before the information receiving module receives the second verification information and the payer's identity authentication information sent by the payer. The access request recording module is used to record the number of access requests received, authenticate the accessing user, and obtain the authentication result; In some embodiments, the count recording module further includes: The identifier acquisition unit is used to acquire the first identity identifier of the accessing user's social application; The first verification unit is used to pass identity verification if the first identity identifier of the social application matches the second identity identifier of the social application recorded by the transaction verification mini-program server, or if the second identity identifier of the social application is empty. The second verification unit is used to prevent identity verification from succeeding if the first identity identifier of the social application is inconsistent with the second identity identifier of the social application recorded by the transaction verification mini-program server.

[0158] In some embodiments, the count recording module further includes: The token extraction unit is used to extract a one-time verification token from the access link; The feature acquisition unit is used to acquire at least one verification-related feature of the accessing user when the record status of the one-time verification token is valid. The algorithm processing unit is used to input the verification-related features into the preset verification algorithm to obtain the comprehensive verification result; In some embodiments, the verification association features include the payer's IP address, request timestamp, and device fingerprint information, and the algorithm processing unit includes: The geo-computing subunit is used to calculate the geographical deviation between the IP address and the payee's IP address recorded when the one-time verification token was generated; The time calculation subunit is used to calculate the time interval between the request timestamp and the generation timestamp of the one-time verification token, based on the request timestamp. The matching calculation subunit is used to calculate the matching degree between the device fingerprint information and the payee device fingerprint information recorded when the one-time verification token is generated; The comparison sub-unit is used to compare the geographical deviation, time interval, and matching degree with the corresponding preset thresholds and obtain the corresponding comparison results. The sub-unit is used to enable identity verification if the comparison result meets the preset judgment conditions. The "Failed" sub-unit is used to prevent authentication from succeeding if the comparison result does not meet the preset judgment conditions.

[0159] The result output unit is used to output the identity verification result based on the comprehensive verification result.

[0160] The interface allows the display of a second verification interface on the payer's transaction verification mini-program client when the number of requests is less than the preset number and the authentication result indicates that the accessing user is the payer. The interface blocking module is used to prevent the display of the second verification interface on the payment party's transaction verification mini-program client when the number of requests is less than the preset number and / or the authentication result indicates that the accessing user is not the payment party.

[0161] In some embodiments, the transaction verification mini-program server 60 may further include the following modules: The task generation module is used to generate a unique verification task identifier corresponding to this verification before the token extraction unit extracts the one-time verification token from the access link. The token encryption module is used to encrypt the verification task identifier based on a preset encryption factor to generate a one-time verification token. The link building module is used to generate an access link containing a one-time verification token.

[0162] In some embodiments, the transaction verification mini-program server 60 may further include the following modules: The background verification module is used to verify whether the background information of the first transaction and the background information of the second transaction are consistent before the normal judgment module determines that the transaction to be verified is a normal transaction. The first answer verification module is used to verify whether the answers to the first questionnaire match the first preset rule. The second answer verification module is used to verify whether the answers to the second questionnaire match the second preset rules.

[0163] In some embodiments, the transaction verification mini-program server 60 may further include the following modules: The forwarding record module is used to record the number of times the recipient forwards the access link; The forwarding prohibition module is used to prevent the recipient from forwarding the access link again after the preset number of forwards has been reached.

[0164] The various modules of the query device provided in this application embodiment can achieve Figure 2 It provides the functionality for each step of the query method and achieves the corresponding technical effect. For the sake of brevity, it will not be elaborated here.

[0165] Figure 7 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0166] The electronic device may include a processor 701 and a memory 702 storing computer program instructions.

[0167] Specifically, the processor 701 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0168] Memory 702 may include mass storage for data or instructions. For example, and not limitingly, memory 702 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 702 may include removable or non-removable (or fixed) media. Where appropriate, memory 702 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 702 is non-volatile solid-state memory.

[0169] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0170] The processor 701 implements any of the query methods described in the above embodiments by reading and executing computer program instructions stored in the memory 702.

[0171] In one example, the electronic device may also include a communication interface 703 and a bus 710. For example, Figure 7 As shown, the processor 701, memory 702, and communication interface 703 are connected through bus 710 and complete communication with each other.

[0172] The communication interface 703 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0173] Bus 710 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 710 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0174] The transaction verification methods described in the above embodiments can be implemented using a computer storage medium. This computer storage medium stores computer program instructions; when these instructions are executed by a processor, they implement any of the transaction verification methods described in the above embodiments.

[0175] This application also provides a computer program product, including a computer program, which, when executed, implements any of the transaction verification methods described in the above embodiments.

[0176] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0177] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0178] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A transaction verification method, characterized in that, Executed by the transaction verification mini-program server, including: Receive first verification information and recipient identity authentication information sent by the recipient of the transaction to be verified; the first verification information is filled in by the recipient on the first verification interface displayed on the transaction verification mini-program client; the transaction verification mini-program is a mini-program embedded in the target social application. If the recipient's identity verification information is successful, an access link for the transaction to be verified is generated; The access link is sent to the payee, so that the payee forwards it to the payer of the transaction to be verified through the target social application. The payer then enters the second verification interface through the access link and fills in the second verification information of the transaction to be verified on the second verification interface. The payee and the payer are contacts of each other in the target social application. Receive the second verification information and the payer's identity authentication information sent by the payer; If the payer's identity authentication information is passed and the first information to be verified and the second information to be verified meet the preset conditions, the transaction to be verified is determined to be a normal transaction; If the first information to be verified and the second information to be verified do not meet the preset conditions, the transaction to be verified is determined to be an abnormal transaction.

2. The method according to claim 1, characterized in that, Before receiving the second verification information and the payer's identity authentication information sent by the payer, the method further includes: Receive access requests from users for the access link; Record the number of access requests received, and authenticate the accessing user to obtain the authentication result; If the number of requests is less than the preset number of requests and the identity verification result indicates that the accessing user is the payer, the second verification interface is allowed to be displayed on the payer's transaction verification mini-program client; If the number of requests is less than the preset number of requests and / or the authentication result indicates that the accessing user is not the payer, the second verification interface shall be prohibited from being displayed on the payer's transaction verification mini-program client.

3. The method according to claim 2, characterized in that, The process of authenticating the accessing user and obtaining the authentication result includes: Obtain the first identity identifier of the accessing user's social application; The identity verification is successful if the first identity identifier of the social application matches the second identity identifier of the social application recorded by the transaction verification mini-program server, or if the second identity identifier of the social application is empty. If the first identity identifier of the social application is inconsistent with the second identity identifier of the social application recorded by the transaction verification mini-program server, the identity verification fails.

4. The method according to claim 2, characterized in that, The process of authenticating the accessing user and obtaining the authentication result includes: Extract a one-time verification token from the access link; If the record status of the one-time verification token is valid, obtain at least one verification association feature of the accessing user; The verification-related features are input into a preset verification algorithm to obtain a comprehensive verification result; Based on the comprehensive verification results, the identity verification result is output.

5. The method according to claim 4, characterized in that, The verification association features include the payer's IP address, request timestamp, and device fingerprint information. The step of inputting these verification association features into a preset verification algorithm to obtain a comprehensive verification result includes: Based on the IP address, calculate its geographical deviation from the payee's IP address recorded when the one-time verification token was generated; Based on the request timestamp, calculate the time interval between it and the generation timestamp of the one-time verification token; Based on the device fingerprint information, calculate its matching degree with the payee device fingerprint information recorded when the one-time verification token was generated; The geographical deviation, the time interval, and the matching degree are compared with their respective preset thresholds, and the corresponding comparison results are obtained. If the comparison result meets the preset judgment conditions, the identity verification is successful; If the comparison result does not meet the preset judgment condition, the identity verification fails.

6. The method according to claim 4, characterized in that, Prior to retrieving the one-time verification token from the access link, the method further includes: Generate a unique verification task identifier that corresponds to this verification. The verification task identifier is encrypted based on a preset encryption factor to generate the one-time verification token; Based on the one-time verification token, the access link containing the token is generated.

7. The method according to any one of claims 1-6, characterized in that, The first information to be verified includes first transaction background information and / or a first questionnaire; the second information to be verified includes second transaction background information and / or a second questionnaire; and before the payer's identity authentication information is passed and the first and second information to be verified meet preset conditions, the method further includes: Verify whether the first transaction background information and the second transaction background information are consistent; And / or verify whether the answers to the first questionnaire match the first preset rule; And / or verify whether the answers to the second questionnaire match the second preset rule.

8. The method according to any one of claims 1-6, characterized in that, The method further includes: Record the number of times the recipient forwards the access link; If the number of forwards reaches the preset number, the recipient is prohibited from forwarding the access link further.

9. A transaction verification mini-program server, characterized in that, The server includes: The first information receiving module is used to receive the first verification information and the recipient's identity authentication information sent by the recipient of the transaction to be verified; the first verification information is filled in by the recipient on the first verification interface displayed on the transaction verification mini-program client; the transaction verification mini-program is a mini-program embedded in the target social application. The link generation module is used to generate an access link for the transaction to be verified when the recipient's identity authentication information is passed. The link sending module is used to send the access link to the payee, so that the payee forwards it to the payer of the transaction to be verified through the target social application, thereby enabling the payer to enter the second verification interface through the access link and fill in the second verification information of the transaction to be verified on the second verification interface; the payee and the payer are contacts of each other in the target social application; The second information receiving module is used to receive the second verification information and the payer's identity authentication information sent by the payer; The normal determination module is used to determine that the transaction to be verified is a normal transaction when the payer's identity authentication information passes and the first information to be verified and the second information to be verified meet preset conditions. The anomaly determination module is used to determine that the transaction to be verified is an abnormal transaction if the first information to be verified and the second information to be verified do not meet preset conditions.

10. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the transaction verification method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the transaction verification method as described in any one of claims 1-8.

12. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the transaction verification method as described in any one of claims 1-8.

Images