Payment transaction method and system, electronic equipment, storage medium and program product
By introducing an auxiliary user verification mechanism, the problem of account verification failure for elderly users was solved, transactions were successfully completed, and the verification and transaction success rates were improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA UNIONPAY
- Filing Date
- 2026-01-29
- Publication Date
- 2026-05-08
AI Technical Summary
Elderly users experience a high failure rate when verifying their accounts due to reasons such as forgetting passwords, worn fingerprints, and unstable facial expressions, which affects the completion of transactions.
An auxiliary user verification mechanism is introduced, in which an auxiliary user bound to the user performs a one-time verification. The verification result of the auxiliary user is regarded as the user's own completion, thereby achieving the continuity of the transaction process and the controllability of risks.
It improves the account verification success rate and transaction success rate for elderly users, while taking into account technical feasibility, user experience, and system compliance.
Smart Images
Figure CN121998645A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of digital payment technology, and in particular relates to a payment transaction method, system, electronic device, storage medium and program product. Background Technology
[0002] With the widespread adoption of digital payments and online financial services, password verification, biometric recognition (such as fingerprints and facial recognition), and SMS verification codes have become the mainstream methods for account security verification. However, some users may encounter problems such as difficulty remembering passwords, worn fingerprints, unstable facial expressions, and poor lighting or device compatibility, resulting in a high failure rate and situations where multiple attempts are not enough to complete a transaction.
[0003] Therefore, there is an urgent need for a way to improve the success rate of user account verification. Summary of the Invention
[0004] This application provides a payment transaction method, system, electronic device, storage medium, and program product that can improve the success rate of user account verification, thereby improving the transaction success rate.
[0005] In a first aspect, embodiments of this application provide a payment transaction method, including: In response to a user initiating a transaction request on the transaction page, the user's account is verified; During the user's account verification process, if the auxiliary verification triggering conditions are met, a one-time verification request is sent to each target auxiliary user in the target auxiliary user set bound to the user. For each target auxiliary user who responds to a one-time verification request, the target auxiliary user is verified using the verification method corresponding to the target auxiliary user; In response to receiving a successful verification result from any target auxiliary user within the validity period of the verification request, the system determines that the user's account has been successfully verified and sends a payment request to deduct funds from the user's account.
[0006] Secondly, embodiments of this application provide a payment transaction system, including: The native verification module is used to verify the user's account in response to a transaction request initiated by the user on the transaction page; The verification management module is used to send a one-time verification request to each auxiliary user in the set of auxiliary users bound to the user during the user's account verification process, provided that the auxiliary verification triggering conditions are met. The verification management module is also used to verify each target auxiliary user who responds to a one-time verification request, using a verification method corresponding to the target auxiliary user. The verification management module is also used to respond to a verification result indicating successful verification sent by any target auxiliary user within the validity period of the verification request, determine that the user's account has been successfully verified, and send a payment request to deduct funds from the user's account.
[0007] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; When the processor executes computer program instructions, it implements payment transaction methods as described in the first aspect.
[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the payment transaction method as described in the first aspect.
[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by the processor of an electronic device, cause the electronic device to perform the payment transaction method as described in the first aspect.
[0010] In this embodiment, in response to a user initiating a transaction request on the transaction page, the user's account is verified. During the account verification process, if the auxiliary verification triggering conditions are met, a one-time verification request is sent to each auxiliary user in the set of auxiliary users bound to the user. For each target auxiliary user responding to the one-time verification request, the target auxiliary user is verified using a verification method corresponding to the target auxiliary user. In response to receiving a verification result indicating successful verification from any target auxiliary user within the validity period of the verification request, the user's account verification is determined to be successful, and a payment request is sent to the payment system to deduct funds from the user's account. According to this embodiment, an auxiliary verification mechanism is introduced in the user's account verification stage, enabling the user to successfully complete the transaction process through verification by the bound auxiliary users even if the user is unable to complete the verification due to reasons such as biometric recognition failure, thereby improving the user's account verification success rate and transaction success rate. Attached Figure Description
[0011] 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.
[0012] Figure 1 These are schematic diagrams of a payment transaction system provided in some embodiments of this application; Figure 2 This is a flowchart of a payment transaction method provided in some embodiments of this application; Figure 3 This is a flowchart of a payment transaction method provided in some embodiments of this application; Figure 4 These are schematic diagrams of a payment transaction system provided in some embodiments of this application; Figure 5 These are schematic diagrams of the structure of electronic devices provided in some embodiments of this application. Detailed Implementation
[0013] 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.
[0014] 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 said element.
[0015] Before providing a more detailed description of the embodiments of this application, the relevant technologies will be introduced. As mentioned above, due to problems such as elderly users not being able to remember passwords, worn fingerprints, unstable facial expressions, poor light or device compatibility, their verification failure rate is significantly higher than that of ordinary users, and they often fail to complete the transaction even after multiple attempts.
[0016] Research on the payment experience and security behavior of elderly users revealed that industry technologies related to identity verification and age-friendly payment experiences mainly fall into the following categories: Age-friendly interface and simplified operation: Many payment apps and banking apps offer "senior mode" or "age-friendly interface", which mainly focuses on visual and operational optimizations, such as enlarging fonts, simplifying pages, adding voice prompts, and using high-contrast colors, aiming to improve the convenience of using the app for elderly users.
[0017] Voice prompts and human assistance mechanisms after biometric recognition failure: In some apps, when a user fails to verify multiple times in a row, the system will play a voice prompt to guide the user to adjust the lighting, angle, or try to verify again; a few platforms provide "human customer service" or "help center" entrances on the verification page to guide users to verify their identity.
[0018] Family Protection and Transaction Alert Mechanisms: Some payment platforms have explored introducing "Family Protection" or "Family Account" functions to enhance the security management experience for senior citizens' accounts. Through these functions, users can invite family members to activate the protection service. When a protected member is suspected of encountering account risks (such as abnormal transfers or suspected fraud), the system will promptly send notifications to both the protected member and their guardian, reminding them to verify the transaction and thus reducing the risk of being scammed.
[0019] Despite various attempts in the industry, the above-mentioned technical solutions still have key shortcomings in the following aspects: The age-friendly interface and simplified operation only address the interface level and do not address the success rate of verification itself. While measures such as enlarged fonts and high-contrast buttons improve visibility, they cannot solve fundamental obstacles such as memory decline, fingerprint wear, and difficulty in facial recognition. The verification process still requires the user to complete it themselves. When elderly users are forced to retry multiple times due to verification failures, the system lacks intelligent guidance or assistance mechanisms, resulting in a poor transaction experience.
[0020] The interaction between voice prompts and human assistance mechanisms after verification failure is simplistic, relying heavily on elderly users' independent understanding and operation. Even when the system provides voice broadcasts or text prompts, elderly users may still be unable to effectively complete payment verification due to hearing impairment, reaction speed, cognitive difficulties, or worn fingerprints. Moreover, the human assistance process is complex and time-consuming, with verification taking a long time after connecting to human customer service, making it unsuitable for real-time scenarios such as payments.
[0021] The intervention of the family guardianship and transaction alert mechanism is lagging behind, failing to provide assistance during the verification stage. Guardians only receive notifications or approval information after a transaction is initiated, which cannot solve the problem of verification difficulties for the elderly.
[0022] It is evident that although the industry has introduced features such as age-friendly interfaces and voice broadcasts, it still mainly focuses on improving the usability of the interface layer, and lacks an effective solution to the key pain point of "senior citizens failing to complete transactions due to verification failures".
[0023] In view of this, to improve the verification success rate for elderly users and thus the transaction success rate, this application provides a payment transaction method, system, electronic device, storage medium, and program product. Addressing the difficulties elderly users and other users face in the verification process, leading to frequent verification failures and impacting transaction completion, an authoritative and traceable "assisted user verification" mechanism is introduced without altering the transaction entity or fund security. For example, when an elderly user fails multiple times or voluntarily gives up during account verification, a linked assisted user can be triggered to complete the verification through their terminal. The verification result is considered equivalent to the elderly user's own completion, thereby achieving a balance between continuity and risk control in the verification process. This solution considers technical feasibility, user experience, and system compliance, and is applicable to various scenarios such as payment, transfer, and account login.
[0024] The payment method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be noted that the payment transaction method provided in the embodiments of this application can be executed by a payment transaction system (hereinafter referred to as "system") deployed on a payment service platform or a financial institution's backend server.
[0025] See Figure 1 This is a schematic diagram of the system architecture of the payment transaction system provided in the embodiments of this application, as shown below. Figure 1 As shown, the system may include a user management module, a verification management module, and a result processing and auditing module.
[0026] The user management module is primarily responsible for the real-name registration, relationship binding, and permission management of users and auxiliary users. Users (such as elderly users or ordinary users) can receive binding requests from auxiliary users after registering in financial service apps (such as payment apps, banking apps, etc.), or users can proactively initiate binding requests to the auxiliary users they wish to bind with after registration. To mitigate security risks, auxiliary users can be adult users who have passed real-name authentication and are not listed on blacklists or graylists. Blacklists and graylists refer to authoritative lists of accounts or users with high-risk or negative records.
[0027] In some embodiments, in order to prevent the binding between a user and an auxiliary user from being maliciously exploited, the system may automatically set an effective waiting period (e.g., 48 hours) after the binding relationship is established. During the effective waiting period, the binding relationship is in an invalid state and is prohibited from being used to perform alternative verification operations. After the effective waiting period, the binding relationship automatically becomes effective and can be used to perform alternative verification operations.
[0028] The user management module also maintains the binding mapping relationship between users and auxiliary users in the database, recording key data such as binding time, effective status, user and auxiliary user identity information, and historical verification records. When a user adds, deletes, or modifies an auxiliary user, the system can simultaneously notify the user and auxiliary user through multiple channels such as App push notifications and SMS, ensuring the transparency and traceability of the binding change process, thereby forming a complete authorization management and auditing closed loop.
[0029] The verification management module is primarily responsible for the entire process of verification failure detection, verification abandonment detection, auxiliary verification triggering, notification issuance, and verification execution, integrating with the existing payment verification process of financial service apps. When the system detects that a user's account verification has failed N times consecutively, or when the user actively clicks "Abandon Verification," a pop-up window will automatically prompt the user whether to enable "Auxiliary Verification." After the user confirms enabling "Auxiliary Verification," the system can generate a digital credential token with an expiration date based on the transaction elements of the user's current transaction (such as order number, amount, timestamp, user account, and auxiliary user identity). This token is used as a one-time verification request and can be sent to all bound and active auxiliary users through multi-channel parallel notifications. After the auxiliary user clicks the notification and enters the verification page, the system can verify the auxiliary user using the verification method corresponding to that user.
[0030] In some embodiments, the verification method corresponding to the auxiliary user can be determined based on the transaction amount and the auxiliary user's credit rating.
[0031] During the assisted user verification process, the client can prompt the user to wait and poll for the assisted user's verification result. If the user chooses to close the transaction page while waiting for the assisted user's verification, the system can provide two options: "close the page but continue to wait" and "abandon the transaction directly". The former keeps the transaction in a waiting state in the background, and the system will automatically complete the payment and deduction after the assisted user completes the verification within the token's validity period. The latter will immediately terminate the transaction and invalidate all tokens.
[0032] The system can monitor the entire verification process in real time in the background. Once any assisted user successfully verifies the transaction, the system can immediately invalidate the remaining tokens to ensure the uniqueness of the transaction and trigger a payment request.
[0033] In addition, if no assisting user responds or all assisting users fail to verify before the token expires, the system can terminate the assisting verification process and prompt the user to retry.
[0034] The results processing and auditing module is primarily responsible for verifying the feedback of results, synchronizing status, and auditing logs. After verification, the results processing and auditing module can synchronize the verification results, timestamps, and transaction status of the auxiliary user to the transaction system, and generate a complete operation log (which may include the verifier, time, channel, device identifier, network environment, etc.). The log can be further encrypted and stored for auditing and accountability.
[0035] The results processing and auditing module can also send notifications through multiple channels when the binding relationship between users changes, preventing malicious replacement or impersonation, thus forming a secure closed loop in the verification chain and ensuring the consistency of the system state.
[0036] The payment transaction method provided in the embodiments of this application will be described below based on the aforementioned payment transaction system.
[0037] See Figure 2 The payment transaction method provided in some embodiments of this application may include the following steps 210-240, which will be described in detail below.
[0038] Step 210. In response to the user initiating a transaction request on the transaction page, verify the user's account.
[0039] In some embodiments of this application, the system triggers an account verification process for the user when it detects that the user has initiated a transaction request (such as payment or transfer) on the transaction page.
[0040] In some embodiments of this application, user account verification may employ at least one of the following verification methods: password verification, biometric identification, and SMS verification code verification. Biometric identification may include, but is not limited to, fingerprint recognition, facial recognition, iris recognition, and voiceprint recognition.
[0041] Step 220. During the user's account verification process, if the auxiliary verification triggering conditions are met, send a one-time verification request to each auxiliary user in the set of auxiliary users bound to the user.
[0042] In some embodiments of this application, the system can detect whether the original verification process can continue during the user's account verification process. If it is determined that the original verification process cannot continue, the system determines that the auxiliary verification triggering condition is met, thereby triggering the auxiliary verification mechanism to perform auxiliary verification through an auxiliary user bound to the user.
[0043] In some embodiments of this application, the determination that the native verification process cannot continue can be based on the following two types of events: one is that the user fails verification multiple times consecutively, and the other is that the user actively abandons verification. Based on this, the auxiliary verification triggering condition may include at least one of the following: The user has failed authentication N times consecutively, where N≥1; User abandons verification.
[0044] As an example, the system can detect whether the user fails to verify during the verification process, and whether the user actively abandons the verification (e.g., whether the control used to indicate abandoning verification is triggered). After detecting that the user fails to verify N times consecutively or actively abandons verification, the system can determine that the auxiliary verification triggering condition is met, and thus trigger auxiliary verification.
[0045] In some embodiments of this application, considering that users may want to abandon the transaction after multiple verification failures or when they actively give up verification, in order to avoid erroneous payments caused by automatically triggering auxiliary verification based on auxiliary verification trigger conditions, when it is determined that the auxiliary verification trigger conditions are met, the system may first prompt the user whether to enable "auxiliary verification" through automatic pop-up windows or other means before performing auxiliary verification through the auxiliary user bound to the user. If the user confirms that "auxiliary verification" has been enabled, then auxiliary verification will be performed through the auxiliary user.
[0046] In some embodiments of this application, assisted verification via auxiliary users includes sending a one-time verification request to each auxiliary user in a set of auxiliary users bound to the user. The set of auxiliary users bound to the user may include one or more auxiliary users. If multiple auxiliary users are included, one-time verification requests may be sent to multiple auxiliary users simultaneously to strive for at least one successful verification response in the shortest possible time, thereby resuming and advancing the transaction process.
[0047] In some embodiments of this application, in order to achieve assisted user verification, the system may first establish a binding relationship between the user and the assisted user before step 220 above. The binding relationship between the user and the assisted user can be established in the following manner: In response to receiving a binding request that instructs the auxiliary user to bind with the user, determine whether the auxiliary user is an adult user who has passed real-name authentication and whether the auxiliary user is included in a preset list; if the auxiliary user is an adult user who has passed real-name authentication and the auxiliary user is not included in the preset list, establish a binding relationship between the auxiliary user and the user, and set the binding relationship to take effect after an effective waiting period.
[0048] As an example, after a user completes registration in a financial services app, an auxiliary user registered in the same app can initiate a binding request to the aforementioned user they wish to bind. The binding request can include the user's information (such as name, phone number, etc.) and the auxiliary user's information. The user can receive this binding request through the financial services app and can choose to "accept" or "reject" it based on their needs. If the user chooses to "accept," the system receives the request and verifies the auxiliary user's information to confirm whether the auxiliary user is a verified adult and whether they are on a pre-defined blacklist or graylist. If the system confirms that the auxiliary user is a verified adult and not on a blacklist or graylist, the binding relationship between the auxiliary user and the user is established. This binding relationship automatically takes effect after a waiting period (e.g., 48 hours). Before the binding relationship takes effect, it cannot be used for auxiliary verification. The auxiliary user's information can be included in the binding request or automatically uploaded and stored in the system when the auxiliary user registers for the financial services app.
[0049] As another example, after registering in a financial services app, a user can proactively initiate a binding request to other users registered with the same app (i.e., the auxiliary user the user wants to bind). The auxiliary user to be bound can receive the binding request through the financial services app. The auxiliary user can choose to "accept" or "reject" the binding request based on their actual needs. If the auxiliary user chooses to "accept" the binding request, the system can receive the binding request and, upon receiving the binding request, review the auxiliary user's user information to verify whether the auxiliary user is a real-name authenticated adult user and check whether they are on a preset blacklist or graylist. If it is determined that the auxiliary user is a real-name authenticated adult user and is not on the blacklist or graylist, the binding relationship between the auxiliary user and the user is established, and the binding relationship is automatically set to take effect after an effective waiting period (e.g., 48 hours). Before the binding relationship takes effect, it cannot be used for auxiliary verification. The auxiliary user's user information can be included in the binding request or automatically uploaded when the auxiliary user registers for the financial services app and stored in the system.
[0050] In some embodiments of this application, for each auxiliary user, the one-time verification request sent to that user can be generated based on transaction elements (such as order number, transaction amount, timestamp, user account identifier, etc.) and the auxiliary user's identity information (such as identity identifier, etc.) in the transaction initiated by the user. Specifically, for each auxiliary user, a digital credential token with a validity period can be generated based on the transaction elements of the current transaction and the auxiliary user's identity information, and this token serves as the one-time verification request corresponding to that auxiliary user. The validity period of the token is the validity period of the one-time verification request, i.e., the verification request validity period. The length of the validity period can be set according to actual needs, for example, it can be set to 10 minutes. In this way, each auxiliary user can obtain a unique and time-sensitive verification request.
[0051] In some embodiments of this application, to enable assisted users to respond quickly to one-time verification requests, a multi-channel parallel sending method can be used to send one-time verification requests to assisted users. For example, one-time verification requests can be sent to assisted users in parallel through three channels: financial service app push notifications, SMS-specific links, and voice reminders.
[0052] Step 230. For each target auxiliary user responding to a one-time verification request, verify the target auxiliary user using the verification method corresponding to the target auxiliary user.
[0053] In some embodiments of this application, after sending a one-time verification request to the auxiliary user, the auxiliary user may return response information to the system indicating that the one-time verification request has been received. Upon receiving the response information, the system may identify the auxiliary user as the target auxiliary user who can currently perform auxiliary verification. Then, the system may determine the verification method corresponding to the target auxiliary user based on the elements in the one-time verification request, and send a verification method instruction to the target auxiliary user, thereby verifying the target auxiliary user based on the verification method corresponding to the target auxiliary user.
[0054] In some embodiments of this application, to achieve risk adaptation, multiple verification methods, such as password-free access, low-level verification, and high-level verification, can be established based on the transaction amount and the credit rating of the target auxiliary user. This allows for the dynamic allocation of different verification methods to different target auxiliary users. Therefore, before verifying a target auxiliary user using the verification method corresponding to that user, the verification method for each target auxiliary user can be determined based on the transaction amount and the user's credit rating. The credit rating of the target auxiliary user can be determined based on their historical transaction behavior in the financial services app.
[0055] In some embodiments of this application, for each target assistive user, the following rules can be used to determine the verification method corresponding to that target assistive user: If the transaction amount is less than or equal to the first amount threshold and the target auxiliary user's credit rating is first level, the verification method for the target auxiliary user is determined to be sending a transaction notification to the target auxiliary user and allowing the transaction to proceed without a password. If the transaction amount is greater than the first amount threshold but less than the second amount threshold, or if the target assisted user's credit rating is level two, the verification method for the target assisted user is determined to be requiring the target assisted user to complete a low-level verification; wherein, level two is lower than level one. If the transaction amount is greater than or equal to the second amount threshold, or if the target assisted user's credit rating is level three, the verification method for the target assisted user is determined to be requiring the target assisted user to complete advanced verification; wherein, level three is lower than level two, and the complexity of advanced verification is greater than that of low-level verification.
[0056] The first amount threshold, the second amount threshold, the first level, and the second level can be set based on actual needs.
[0057] In some embodiments of this application, low-level verification may be a simple single-factor verification, while high-level verification may be a more complex multi-factor verification. For example, low-level verification may employ any one of SMS verification code verification, biometric identification, and password verification. High-level verification may employ a combination of at least two of SMS verification code verification, biometric identification, and password verification.
[0058] The above method allows for the determination of the verification process and interaction method for the target user during auxiliary verification, based on the transaction amount and the target user's credit rating. This overcomes the limitations of traditional identity verification, which is characterized by "single strength and fixed experience." It dynamically selects the optimal verification method from multiple verification levels, such as password-free access, low-level verification, and high-level verification, according to the specific risk level of each transaction. This solution ensures a secure closed loop for high-risk transactions without downgrading, while providing a seamless experience for high-frequency, low-amount transactions. Therefore, this solution combines high user-friendliness, risk controllability, and commercial viability.
[0059] Step 240. In response to receiving a verification result indicating successful verification from any target auxiliary user within the validity period of the verification request, determine that the user's account has been successfully verified, and send a payment request to deduct funds from the user's account.
[0060] In some embodiments of this application, the verification result of the target auxiliary user is treated as the verification result of the user initiating the transaction in the system. During the auxiliary verification process, the system polls the verification status of each target auxiliary user. Upon receiving a verification result indicating successful verification from any target auxiliary user, the system determines that the user's account has been successfully verified. This allows the system to initiate a payment request to the payment system used for deduction, enabling the payment system to deduct funds from the user's account and complete the transaction. This effectively improves the verification success rate and maintains the continuity of the transaction process.
[0061] In some embodiments of this application, when there are at least two auxiliary users in the set of auxiliary users bound to a user, to ensure transaction uniqueness, if any target auxiliary user successfully verifies, the one-time verification requests sent to other auxiliary users are set to an invalid state. These other auxiliary users are those in the auxiliary user set other than the successfully verified target auxiliary user. That is, when any target auxiliary user successfully completes verification, the system can immediately invalidate the tokens of other auxiliary users and initiate a unique payment request. This achieves a "first-come, first-served" mechanism, completely avoiding duplicate deductions or state competition. This design improves response speed and ensures the security and consistency of the payment chain, meeting the needs of high-concurrency, real-time transaction scenarios.
[0062] In this embodiment, in response to a user initiating a transaction request on the transaction page, the user's account is verified. During the account verification process, if the auxiliary verification triggering conditions are met, a one-time verification request is sent to each auxiliary user in the set of auxiliary users bound to the user. For each target auxiliary user responding to the one-time verification request, the target auxiliary user is verified using a verification method corresponding to the target auxiliary user. In response to receiving a verification result indicating successful verification from any target auxiliary user within the validity period of the verification request, the user's account verification is determined to be successful, and a payment request is sent to the payment system to deduct funds from the user's account. According to this embodiment, an auxiliary verification mechanism is introduced in the user's account verification stage, enabling the user to successfully complete the transaction process through verification by the bound auxiliary users even if the user is unable to complete the verification due to reasons such as biometric recognition failure, thereby improving the user's account verification success rate and transaction success rate.
[0063] In some embodiments of this application, to enhance transaction flexibility, the payment transaction method provided in this application may further include: Before receiving a verification result indicating successful verification from any target user, in response to receiving the user's action of closing the transaction page, output a first option and a second option to the user. The first option is used to indicate that the transaction page is closed and the transaction continues, while the second option is used to indicate that the transaction is abandoned. In response to receiving the user's selection of the first option, the transaction page is closed, and the system continues to receive verification results from the target assisted user to complete the transaction based on the received verification results; or, Upon receiving the user's selection of the second option, the transaction is terminated, and a one-time verification request is sent to each target assistant user to set it to an invalid state.
[0064] During the verification process, the terminal used by the user initiating the transaction may prompt the user to wait. If the user chooses to close the transaction page while waiting for verification, the system will offer two options: "Close the page but continue waiting" and "Abandon the transaction." The user can choose one according to their needs. If the user chooses "Close the page but continue waiting," the transaction page on the terminal will be closed, and the transaction will remain in a waiting state in the background. This way, if any target user successfully verifies the transaction within the token's validity period, the payment will still be automatically deducted. However, if the user chooses "Abandon the transaction," the transaction will be immediately terminated, and all tokens will be invalidated.
[0065] Through the above design, during the auxiliary verification period, users can flexibly choose whether to continue the transaction and ensure the atomicity of the transaction.
[0066] In some embodiments of this application, during auxiliary verification, the verification result can be sent to the terminal of the user who initiated the transaction in real time, so that the user can understand the transaction status in real time.
[0067] In some embodiments of this application, to facilitate auditing and accountability, the payment transaction method may further include the following steps: Record the entire process of this account verification in the operation log. The operation log includes at least one of the following: verified user, verification time, request sending method, device identifier, and network environment information; where the verifier is the first target auxiliary user who is successfully verified.
[0068] In practical applications, after account verification is completed, the verification result, timestamp, and transaction status of the assisting user can be synchronously updated to the trading system, generating a complete operation log (including the verified user, time, channel (such as App notification, SMS, voice notification), device identifier, network environment, etc.). This operation log is stored in the database, and the transaction status is updated synchronously. In this way, the operation log can be used for risk assessment and compliance review. If disputes or anomalies subsequently occur, the system can trace the entire process of assisting verification based on the logs, ensuring that the boundaries of responsibility are clearly traceable.
[0069] In some embodiments of this application, when storing operation logs, symmetric or asymmetric encryption algorithms can be used to encrypt the operation logs to improve data security. The encryption algorithm used can be set according to actual needs, and this embodiment does not impose specific limitations on it.
[0070] In some embodiments of this application, users can edit (delete, modify, or add) their corresponding binding relationships in a financial services app. When the binding relationship changes, the system can send change notifications to the users and auxiliary users bound to the changed binding relationship through multiple channels (such as app reminders, SMS, and voice reminders) to prevent malicious replacement or impersonation, form a secure closed loop of the verification link, and ensure the consistency of the system state.
[0071] In some embodiments of this application, both the user and the assistant user can view the corresponding binding relationship in the financial services app, and can also adjust their notification preferences for unbinding or adjusting the binding relationship. The system can notify both parties through multiple channels, including the message center and SMS, after each operation by either the user or the assistant user, ensuring the transparency and security of the authorization status.
[0072] In some embodiments of this application, if the system does not receive a response from any auxiliary user within the validity period of the verification request, or if all target auxiliary users fail to verify, the system may automatically terminate the transaction and prompt the user to retry, that is, prompt the user to re-initiate the transaction.
[0073] To facilitate understanding, the following will be combined with Figure 3 Taking a scenario where an elderly user initiates a transaction as an example, this application describes the process of making a payment transaction using an embodiment of the present application. Figure 3 As shown, the process may include the following steps a1-a13.
[0074] Step a1. In response to an elderly user initiating a transaction, perform an account verification process for the elderly user.
[0075] Step a2. Determine whether the elderly user's verification has failed N times consecutively, or whether the elderly user has voluntarily given up verification. If not, proceed to step a3; if yes, proceed to step a4.
[0076] Step a3. Continue the original verification process.
[0077] Step a4. Prompt elderly users to enable assisted verification. If not, proceed to step a5; if yes, proceed to step a6.
[0078] Step a5. Verify elderly users or terminate transactions using the existing verification methods.
[0079] Step a6. Enable auxiliary verification and generate a one-time verification request.
[0080] Step a7. Send a one-time verification request to each assistive user bound to the elderly user in parallel through multiple channels.
[0081] Step a8. Determine if any auxiliary user has successfully verified within the validity period of the verification request. If not, proceed to step a9; if yes, proceed to step a10.
[0082] Step a9. Terminate the transaction and prompt the elderly user to try again.
[0083] Step a10. Determine whether the elderly user has abandoned the transaction. If yes, proceed to step a11; otherwise, proceed to step a12.
[0084] Step a11. Terminate the transaction, remind the assistant user that the transaction is terminated and destroy each assistant user's one-time verification request.
[0085] Step a12. Real-time transmission of the verification result of the successfully verified auxiliary user, invalidation of the one-time verification requests of other auxiliary users, and execution of payment and deduction for the unique transaction.
[0086] Step a13. Generate and store the operation log.
[0087] Based on the payment transaction method provided in the above embodiments, this application also provides specific implementations of the payment transaction system. Please refer to the following embodiments.
[0088] See Figure 4 The payment transaction system 400 provided in this application embodiment includes the following modules: The native verification module 401 is used to verify the user's account in response to a user's transaction request initiated on the transaction page. The verification management module 402 is used to send a one-time verification request to each auxiliary user in the set of auxiliary users bound to the user during the user's account verification process, provided that the auxiliary verification triggering conditions are met. The verification management module 402 is also used to verify each target auxiliary user who responds to a one-time verification request using a verification method corresponding to that target auxiliary user; The verification management module 402 is also used to respond to receiving a verification result indicating successful verification from any target auxiliary user within the validity period of the verification request, determine that the user's account has been successfully verified, and send a payment request to the payment system to deduct funds from the user's account.
[0089] In this embodiment, in response to a user initiating a transaction request on the transaction page, the user's account is verified. During the account verification process, if the auxiliary verification triggering conditions are met, a one-time verification request is sent to each auxiliary user in the set of auxiliary users bound to the user. For each target auxiliary user responding to the one-time verification request, the target auxiliary user is verified using a verification method corresponding to the target auxiliary user. In response to receiving a verification result indicating successful verification from any target auxiliary user within the validity period of the verification request, the user's account verification is determined to be successful, and a payment request is sent to the payment system to deduct funds from the user's account. According to this embodiment, an auxiliary verification mechanism is introduced in the user's account verification stage, enabling the user to successfully complete the transaction process through verification by the bound auxiliary users even if the user is unable to complete the verification due to reasons such as biometric recognition failure, thereby improving the user's account verification success rate and transaction success rate.
[0090] In some embodiments of this application, the verification management module 402 is further configured to: In response to receiving a verification result indicating successful verification from any of the target auxiliary users within the validity period of the verification request, the one-time verification requests sent to other auxiliary users are set to invalid status. The other auxiliary users are the auxiliary users in the auxiliary user set other than the target auxiliary user who has successfully verified.
[0091] In some embodiments of this application, the verification management module 402 is further configured to: For each auxiliary user, a digital credential token with an expiration date is generated based on the transaction elements of this transaction and the auxiliary user's identity information. The token is used as a one-time verification request for the auxiliary user, and the validity period of the request is the same as the validity period of the token. For each target assisted user, the verification method corresponding to the target assisted user is determined based on the transaction amount and the target assisted user's credit rating.
[0092] In some embodiments of this application, the verification management module 402 is specifically used for: If the transaction amount is less than or equal to the first amount threshold and the target auxiliary user's credit rating is first level, the verification method for the target auxiliary user is determined to be sending a transaction notification to the target auxiliary user and allowing the transaction to proceed without a password. If the transaction amount is greater than the first amount threshold but less than the second amount threshold, or if the target assisted user's credit rating is level two, the verification method for the target assisted user is determined to be requiring the target assisted user to complete a low-level verification; wherein, level two is lower than level one. If the transaction amount is greater than or equal to the second amount threshold, or if the target assisted user's credit rating is level three, the verification method for the target assisted user is determined to be requiring the target assisted user to complete advanced verification; wherein, level three is lower than level two, and the complexity of advanced verification is greater than that of low-level verification.
[0093] In some embodiments of this application, low-level verification includes any one of the following verification methods: SMS verification code verification, biometric identification, password verification; Advanced authentication includes a combination of at least two of the following authentication methods: SMS verification code verification, biometric identification, and password verification.
[0094] In some embodiments of this application, the auxiliary verification triggering condition includes at least one of the following: The user has failed authentication N times consecutively, where N≥1; User abandons verification.
[0095] In some embodiments of this application, system 400 further includes a user management module for establishing a binding relationship between users and auxiliary users in the following manner: In response to receiving a binding request that instructs the auxiliary user to be bound to the user, determine whether the auxiliary user is an adult user who has passed real-name authentication, and determine whether the auxiliary user is included in a preset list; If the assistant user is an adult user who has passed real-name authentication and is not included in the preset list, a binding relationship is established between the assistant user and the user, and the binding relationship is set to take effect after the effective waiting period.
[0096] In some embodiments of this application, system 400 further includes a result processing and auditing module, used for: Record the entire process of this account verification in the operation log. The operation log should include at least one of the following: Verify user, verification time, request sending method, device identifier, and network environment information; Among them, the verified user is the first target auxiliary user who is successfully verified.
[0097] In some embodiments of this application, the verification management module 402 is further configured to: In response to receiving a user's action to close the transaction page, the system outputs a first option and a second option to the user. The first option indicates that the transaction page can be closed and the transaction can continue, while the second option indicates that the transaction should be abandoned. In response to receiving the user's selection of the first option, the transaction page is closed, and the system continues to receive verification results from the target assisted user to complete the transaction based on the received verification results; or, Upon receiving the user's selection of the second option, the transaction is terminated, and a one-time verification request is sent to each assistant user to set them to an invalid state.
[0098] The payment transaction system provided in this application embodiment can achieve... Figures 1 to 2 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.
[0099] Figure 5 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.
[0100] Electronic device 500 may include processor 501 and memory 502 storing computer program instructions.
[0101] Specifically, the processor 501 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.
[0102] Memory 502 may include a large-capacity memory for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), a floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to electronic device 500. In a particular embodiment, memory 502 is non-volatile solid-state memory. Memory 502 may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Thus, typically, memory 502 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 performs the operations described in any of the payment transaction methods in the above embodiments.
[0103] The processor 501 implements any of the payment transaction methods described in the above embodiments by reading and executing computer program instructions stored in the memory 502.
[0104] In one example, the electronic device 500 may also include a communication interface 503 and a bus 510. For example, Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.
[0105] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.
[0106] Bus 510 includes hardware, software, or both, that couples components of electronic device 500 together. For example, and not limitingly, the bus may include Accelerated Graphics Port (AGP) or other graphics buses, Enhanced Industry Standard Architecture (EISA) buses, Front Side Bus (FSB), HyperTransport (HT) interconnects, Industry Standard Architecture (ISA) buses, Infinite Bandwidth Interconnects, Low Pin Count (LPC) buses, memory buses, Microchannel Architecture (MCA) buses, Peripheral Component Interconnect (PCI) buses, PCI-Express (PCI-X) buses, Serial Advanced Technology Attachment (SATA) buses, Video Electronics Standards Association Local (VLB) buses, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.
[0107] Furthermore, in conjunction with the payment transaction methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the payment transaction methods in the above embodiments.
[0108] This application also provides a computer program product, including a computer program that, when executed, implements any of the account verification methods described in the above embodiments.
[0109] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.
[0110] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.
[0111] 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.
[0112] 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.
[0113] The above description is merely a specific implementation 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 payment transaction method, characterized in that, include: In response to a user initiating a transaction request on the transaction page, the user's account is verified; During the user's account verification process, if the auxiliary verification triggering conditions are met, a one-time verification request is sent to each auxiliary user in the set of auxiliary users bound to the user. For each target auxiliary user who responds to the one-time verification request, the target auxiliary user is verified using a verification method corresponding to the target auxiliary user; In response to receiving a verification result indicating successful verification from any of the target auxiliary users within the validity period of the verification request, the system determines that the user's account has been successfully verified and sends a payment request to deduct funds from the user's account.
2. The method according to claim 1, characterized in that, The set of auxiliary users includes at least two auxiliary users, and the method further includes: In response to receiving a verification result indicating successful verification from any of the target auxiliary users within the validity period of the verification request, the one-time verification requests sent to other auxiliary users are set to invalid status, wherein the other auxiliary users are auxiliary users in the set of auxiliary users other than the target auxiliary user who has successfully verified.
3. The method according to claim 1, characterized in that, Before sending a one-time verification request to each auxiliary user in the set of auxiliary users bound to the user, the method further includes: For each of the auxiliary users, a digital credential token with an expiration date is generated based on the transaction elements of this transaction and the identity information of the auxiliary user. The token is used as a one-time verification request corresponding to the auxiliary user, and the validity period of the request is the validity period of the token. Before verifying the target auxiliary user using a verification method corresponding to the target auxiliary user, the method further includes: For each target assisted user, the verification method corresponding to the target assisted user is determined based on the transaction amount of this transaction and the credit rating of the target assisted user.
4. The method according to claim 3, characterized in that, The method for determining the verification method corresponding to the target auxiliary user based on the transaction elements of this transaction and the credit rating of the target auxiliary user includes: If the transaction amount is less than or equal to the first amount threshold and the credit rating of the target auxiliary user is the first level, the verification method corresponding to the target auxiliary user is determined to be sending a transaction notification to the target auxiliary user and allowing the transaction to proceed without a password. If the transaction amount is greater than the first amount threshold and less than the second amount threshold, or if the target auxiliary user's credit rating is the second level, then the verification method corresponding to the target auxiliary user is determined to be requiring the target auxiliary user to complete a low-level verification; wherein, the second level is lower than the first level. If the transaction amount is greater than or equal to the second amount threshold, or if the target auxiliary user's credit rating is level three, the verification method corresponding to the target auxiliary user is determined to require the target auxiliary user to complete advanced verification; wherein, the level three is lower than the level two, and the complexity of advanced verification is greater than that of low-level verification.
5. The method according to claim 4, characterized in that, The low-level verification includes any one of the following verification methods: SMS verification code verification, biometric identification, password verification; The advanced verification includes a combination of at least two of the following verification methods: SMS verification code verification, biometric identification, and password verification.
6. The method according to any one of claims 1-5, characterized in that, The auxiliary verification triggering condition includes at least one of the following: The user was detected to have failed verification N times consecutively, where N≥1; The user has abandoned the verification process.
7. The method according to any one of claims 1-5, characterized in that, The method for constructing the binding relationship between the user and the auxiliary user includes: In response to receiving a binding request indicating that the auxiliary user be bound to the user, it is determined whether the auxiliary user is an adult user who has passed real-name authentication, and whether the auxiliary user is included in a preset list; If the auxiliary user is an adult user who has passed real-name authentication and is not included in the preset list, a binding relationship is established between the auxiliary user and the user, and the binding relationship is set to take effect after the effective waiting period.
8. The method according to any one of claims 1-5, characterized in that, The method further includes: Record the entire process of this account verification in the operation log, which includes at least one of the following: Verify user, verification time, request sending method, device identifier, and network environment information; The verification user is the first target auxiliary user to be successfully verified.
9. The method according to any one of claims 1-5, characterized in that, The method further includes: In response to receiving the user's action of closing the transaction page, a first option and a second option are output to the user. The first option is used to indicate that the transaction page is closed but the transaction can continue. The second option is used to indicate that the transaction should be abandoned. In response to receiving the user's selection of the first option, the transaction page is closed, and the system continues to receive the verification result sent by the target assisted user to complete the transaction based on the received verification result; or, In response to receiving the user's selection of the second option, the transaction is terminated, and a one-time verification request is sent to each of the auxiliary users and set to an invalid state.
10. A payment transaction system, characterized in that, include: The native verification module is used to verify the user's account in response to a user initiating a transaction request on the transaction page. The verification management module is used to send a one-time verification request to each auxiliary user in the auxiliary user set bound to the user during the user's account verification process, provided that the auxiliary verification triggering conditions are met. The verification management module is also used to verify each target auxiliary user who responds to the one-time verification request using a verification method corresponding to the target auxiliary user. The verification management module is also configured to respond to receiving a verification result indicating successful verification from any of the target auxiliary users within the validity period of the verification request, determine that the user's account has been successfully verified, and send a payment request to deduct funds from the user's account.
11. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the payment transaction method as described in any one of claims 1-9.
12. 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 payment transaction method as described in any one of claims 1-9.
13. 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 payment transaction method as described in any one of claims 1-9.