Payment link generation method and device and nonvolatile storage medium

Abstract

The invention discloses a payment link generation method and device and a nonvolatile storage medium. The method comprises the steps that account information of a target account is acquired, and the account information comprises at least one of equipment information corresponding to the target account, access information of the target account and the geographic position of the target account; generating an initial payment link based on the account information; encrypting the initial payment link to obtain a target payment link; and loading the target payment link at a preset position in the payment page to obtain a target payment page, the target payment page being used for being displayed to a user side corresponding to the target account. The technical problem that in an existing payment system, the payment link is relatively fixed and is likely to be stolen, so that the security of the payment link is insufficient is solved.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a payment link generation method, device and non-volatile storage medium. Background Art

[0002] Electronic payment is popular among users for its convenience and efficiency. However, as payment methods become simpler, black and gray industries have begun to exploit loopholes in the payment system and try to illegally obtain payment links. Once these links are in the hands of criminals, they can disguise themselves as normal users to make illegal payments and steal funds. This not only causes economic losses to merchants, but also seriously damages the reputation of the payment system and the trust of users. The current payment links are relatively fixed and less secure, and can be easily stolen.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present invention provide a method and device for generating a payment link and a non-volatile storage medium, so as to at least solve the technical problem that in the current payment system, the payment link is relatively fixed and easy to be stolen, resulting in insufficient security of the payment link.

[0005] According to one aspect of an embodiment of the present invention, a method for generating a payment link is provided, comprising: obtaining account information of a target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and a geographic location of the target account; generating an initial payment link based on the account information; encrypting the initial payment link to obtain a target payment link; loading the target payment link at a preset position in a payment page to obtain a target payment page, wherein the target payment page is used to be displayed to a user terminal corresponding to the target account.

[0006] Optionally, an initial payment link is generated based on the account information, including: generating dynamic parameters based on the account information; encrypting the dynamic parameters based on a preset encryption algorithm to obtain encrypted dynamic parameters; splicing the encrypted dynamic parameters to a preset payment link in a preset format to obtain an initial payment link.

[0007] Optionally, before obtaining the account information of the target account, the method includes: receiving a payment request initiated based on the target account; and obtaining the account information of the target account based on the payment request.

[0008] Optionally, when an operation of clicking on a target payment link initiated based on a target account is received, payment verification information is generated; the payment verification information is sent to the target account; and when a verification result returned by the target account is that the verification is passed, the target account is determined to be a safe account, wherein a safe account represents an account that is allowed to perform payment operations.

[0009] Optionally, when the verification result returned by the target account is a verification failure, the payment request issued by the target account is rejected and payment verification information is generated again and sent to the target account.

[0010] Optionally, the payment verification information includes verification information for verifying the account identity of the target account and verification information for verifying the payment environment.

[0011] Optionally, the target payment link becomes invalid after the target account completes the payment operation.

[0012] According to another aspect of an embodiment of the present invention, a payment link generation device is also provided, including: an acquisition module, used to obtain account information of a target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account and the geographic location of the target account; a generation module, used to generate an initial payment link based on the account information; an encryption module, used to encrypt the initial payment link to obtain a target payment link; a setting module, used to load the target payment link at a preset position in a payment page to obtain a target payment page, wherein the target payment page is used to be displayed to a user terminal corresponding to the target account.

[0013] According to another aspect of an embodiment of the present invention, a non-volatile storage medium is provided, the non-volatile storage medium including a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute any one of the above-mentioned payment link generation methods.

[0014] According to another aspect of an embodiment of the present invention, a computer device is provided. The computer device includes a processor, and the processor is used to run a program. When the program is run, any one of the above-mentioned payment link generation methods is executed.

[0015] In an embodiment of the present invention, a payment link generation method is adopted, by obtaining account information of a target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account and the geographic location of the target account; based on the account information, an initial payment link is generated; the initial payment link is encrypted to obtain a target payment link; the target payment link is loaded at a preset position in a payment page to obtain a target payment page, wherein the target payment page is used to display to a user terminal corresponding to the target account, thereby achieving the purpose of multi-layer encryption of the payment link, thereby realizing the technical effect of improving the security of the payment link, and further solving the technical problem in the current payment system that the payment link is relatively fixed and easy to be stolen, resulting in insufficient security of the payment link. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0017] Figure 1 A hardware structure block diagram of a computer terminal for implementing a payment link generation method is shown;

[0018] Figure 2 is a flow chart of a method for generating a payment link according to an embodiment of the present invention;

[0019] Figure 3 It is a structural block diagram of a payment link generation device provided according to an embodiment of the present invention. DETAILED DESCRIPTION

[0020] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0022] According to an embodiment of the present invention, a method embodiment of a method for generating a payment link is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0023] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal for implementing a payment link generation method is shown. Figure 1 As shown, the computer terminal 10 may include one or more (102a, 102b, ..., 102n are used to illustrate) processors (the processor may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0024] It should be noted that the one or more processors and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10. As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0025] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the method for generating a payment link in the embodiment of the present invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the method for generating a payment link of the above-mentioned application program is realized. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0026] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .

[0027] Figure 2 is a flow chart of a method for generating a payment link according to an embodiment of the present invention. Figure 2 As shown, the method comprises the following steps:

[0028] Step S202, obtaining account information of the target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and geographic location of the target account.

[0029] In this step, the account information of the target account can be read. The account information may include the device information corresponding to the target account, such as the device model, IP address, etc., and may also include the access information of the target account, such as the access time of the target account; it may also include the geographic location of the target account. This information corresponds to the target account, which facilitates the subsequent generation of a payment link that is unique to the target account, and helps ensure that the generation and verification process of the payment link can be highly customized for specific users and transaction environments. Security measures. Obtaining the account information of the target account is an important prerequisite for creating a personalized and secure payment link, but this process requires ensuring the security of the user's personal data.

[0030] Step S204: Generate an initial payment link based on the account information.

[0031] In this step, an initial payment link can be generated based on the account information. A unique payment link can be dynamically generated based on user behavior and payment environment. The process of generating an initial payment link based on account information involves encoding the collected user-specific information into the link, which can ensure the security and uniqueness of the link. Specifically, parameters can be encoded based on the account information, and then a unique identifier (such as a UUID) can be created using a random number generator and combined with the processed and encrypted information parameters. The parameters and dynamic identifier are attached to the basic payment link to form the initial payment link.

[0032] Through the above steps, the generated payment link contains dynamic information related to the current transaction and user, and can also be encrypted to enhance security. This link can only be correctly activated under certain conditions (i.e., using the device in the link, within the valid time, and from the correct geographical location), thereby effectively avoiding the risk of illegal misuse of the payment link. At the same time, since the parameters contained in the link are dynamically generated, the payment link for each transaction is different, and even if a link is intercepted, it cannot be used for subsequent transactions.

[0033] Step S206, encrypting the initial payment link to obtain the target payment link.

[0034] In this step, the initial payment link can be encrypted. Through encryption technology, the link is presented as a string that cannot be directly identified in the source code, so as to improve security. The purpose of encryption is to protect sensitive information in the link from being obtained and used by unauthorized third parties. You can choose a suitable encryption algorithm according to security requirements and system environment. Common encryption algorithms include symmetric encryption algorithms (such as AES) and asymmetric encryption algorithms (such as RSA). Symmetric encryption algorithms use the same key for encryption and decryption, while asymmetric encryption algorithms use public key encryption and private key decryption. The combined parameter string is encrypted using the selected encryption algorithm and key. The encryption result is usually a ciphertext that cannot be directly read, which can be a byte sequence or an encoded string. The encrypted ciphertext is formatted to make it suitable for transmission in the network. Common conversions include URL-safe Base64 encoding, which can ensure that the ciphertext will not be misinterpreted in the link. When a user accesses the payment gateway through a payment link, the system will use the corresponding key to decrypt the ciphertext in the link and verify whether the decrypted parameters match the current transaction and user information to confirm the legitimacy of the payment request.

[0035] Through encryption processing, the target payment link maintains a high degree of security during transmission and storage. Even if the link is obtained by an unauthorized third party, they will not be able to parse out the sensitive information in the payment link due to the lack of the correct decryption key, thereby effectively preventing the payment link from being illegally used.

[0036] Step S208, loading the target payment link at a preset position in the payment page to obtain a target payment page, wherein the target payment page is used to be displayed to the user end corresponding to the target account.

[0037] In this step, the target payment link can be loaded in a preset position in the payment page, which can be a hidden position. By designing a special page layout, the payment link is hidden in a position that is not easily noticed by the user. When the user triggers a specific operation or meets certain conditions, the payment link will be activated and displayed.

[0038] Specifically, the generated target payment link and other static data of the payment page can be returned to the front end. After receiving the data from the server, the front end uses the data to dynamically build the payment page. This may include inserting the payment link into a specified location in a pre-designed page template, such as under a "click to pay" button or the submission URL of a payment form. The preset location can be a specific HTML element or a hidden iframe, which can prevent the link from being easily discovered through developer tools or page source code. For example, JavaScript can be used to dynamically insert the payment link when the user triggers the payment button, or the link can be loaded into an element that is not immediately visible when the page loads. After the constructed payment page is loaded, it is displayed to the user of the target account. The payment button or form in the page will guide the user to make a payment operation, at which time the payment link in the preset location will be activated and used to submit the payment request.

[0039] Through the above process, the target payment link is safely loaded at the preset position of the payment page, while ensuring the user-friendly display of the payment page. This design effectively prevents the payment link from being obtained and used by unauthorized third parties, protects the security of transactions, and provides a good user experience.

[0040] Through the above steps, the purpose of multi-layer encryption of payment links is achieved, thereby achieving the technical effect of improving the security of payment links, and further solving the technical problem in the current payment system that payment links are relatively fixed and easy to be stolen, resulting in insufficient security of payment links.

[0041] As an optional embodiment, an initial payment link is generated based on account information, including: generating dynamic parameters based on the account information; encrypting the dynamic parameters based on a preset encryption algorithm to obtain encrypted dynamic parameters; splicing the encrypted dynamic parameters to a preset payment link in a preset format to obtain an initial payment link.

[0042] Optionally, dynamic parameters can be generated based on account information. Specifically, dynamic parameters can include user identity parameters, using user ID or hashed user ID to ensure the uniqueness and security of parameters. Device information parameters, extracting device ID (such as IMEI, MAC address), device type, operating system and other information, may need to be formatted and de-identified, such as using device fingerprint technology. Access information parameters, collect access timestamps, session IDs, etc. to verify the timeliness and continuity of requests. Geographic location parameters, obtain user geographic location information based on IP address or GPS data, and can use geocoding or simplified area identification. Then, according to security requirements and system capabilities, a suitable encryption algorithm, such as AES, RSA, etc., can be selected. A key needs to be prepared before encryption. Symmetric encryption uses a shared key, and asymmetric encryption uses a private key. The above-generated dynamic parameters are combined into a string in a preset format. Then, the combined parameter string is encrypted using the selected encryption algorithm and key to generate encrypted dynamic parameters. A basic payment link, that is, the basic URL of the payment gateway, can be prepared first, and the encrypted dynamic parameters can be converted into a URL-safe format, such as Base64 encoding. The formatted encrypted parameters are then added to the base link, usually as query parameters appended to the end of the URL to obtain the initial payment link.

[0043] Through the above steps, the initial payment link contains encrypted dynamic parameters, ensuring that even if the link is intercepted, attackers cannot easily parse out the key information, thereby improving the security of the payment process. At the same time, each payment link generated is based on the specific information of the transaction at that time and is unique, further enhancing the ability to prevent fraud and duplicate payments.

[0044] As an optional embodiment, before obtaining the account information of the target account, it includes: receiving a payment request initiated based on the target account; and obtaining the account information of the target account based on the payment request.

[0045] Optionally, before obtaining the account information of the target account, it is necessary to first receive a payment request and obtain the account information based on the request. For example, the front end (such as the user interface of the merchant website or application) may provide a payment button or option, and the user clicks the payment button or selects the payment option to trigger the payment request. The payment request usually contains some basic transaction information, such as the order ID, transaction amount, and product description, which can be collected by the front end and sent to the back end server as part of the payment request. After receiving the payment request sent by the front end, the back end server will first perform a preliminary legitimacy and integrity check to ensure that the request comes from a valid session and that the information in the request has not been tampered with. The server will query the database based on the information such as the order ID contained in the payment request to obtain the target account information related to the order, including the account ID, account balance, account status, etc. The server can use a database query language (such as SQL) to obtain detailed information of the target account from the user account database. This may involve querying multiple tables to obtain complete information.

[0046] Through this process, the server can ensure the validity and legality of the payment request before generating the payment link, and obtain accurate information of the target account, laying the foundation for subsequent secure payment processes.

[0047] As an optional embodiment, when an operation of clicking on a target payment link initiated based on a target account is received, payment verification information is generated; the payment verification information is sent to the target account; and when a verification result returned by the target account is that the verification is passed, the target account is determined to be a safe account, wherein a safe account represents an account that is allowed to perform payment operations.

[0048] Optionally, after the user clicks on the payment link, verification can be performed again to ensure security. For example, when the system detects that the target account clicks on the target payment link, it will immediately generate payment verification information. This usually includes a one-time password (OTP), a dynamic verification code, an encrypted session ID, or an additional verification request based on risk analysis (such as biometrics or device fingerprints). The generated payment verification information is customized based on the specific information of the target account (such as account history, login device, geographic location, etc.) and the dynamic parameters of the current payment environment (such as transaction amount, payment time, etc.), ensuring that the information generated each time is unique. The payment verification information is sent to the target account through a secure channel, and common channels include SMS, email, mobile application notifications, or instant messaging services. In order to ensure the secure transmission of information, encryption technology is usually used. After receiving the payment verification information, the user (i.e., the target account holder) needs to enter or confirm this information in the payment system to prove the authenticity of his or her identity and willingness to pay. After receiving the payment verification information returned by the target account and confirming it is correct through the system's verification logic, the system will determine that the target account is a safe account. This usually includes checking the timeliness of the verification information, confirming the matching degree with the sent information, and analyzing the consistency of user behavior. Once the target account is confirmed as a safe account, the system will allow it to make payment operations and complete the transaction process.

[0049] This multi-step security verification process based on payment verification information can effectively prevent unauthorized access and payment fraud, ensuring that only the real account holder performs payment operations in a safe environment, thereby greatly improving the overall security of the payment system and the safety of user funds.

[0050] As an optional embodiment, when the verification result returned by the target account is a verification failure, the payment request issued by the target account is rejected and payment verification information is generated again and sent to the target account.

[0051] Optionally, if the verification result returned by the target account is a verification failure, the current payment process can be terminated immediately and any further payment operations can be blocked. This can prevent potential fraudulent transactions from occurring and protect the user's account security and funds. At the same time, clear feedback information can be provided to the user to inform the reason why the payment request was rejected, usually "verification failed". At the same time, the user is advised to take the next step, such as checking whether the verification information entered is correct, re-login to the account, or contact customer support. The payment verification information can be generated again. For example, in order to provide the user with a second chance to verify, the system will generate new payment verification information again. This step needs to ensure that the newly generated information is random and unique to prevent attackers from bypassing security verification through guessing or replay attacks. After the first verification fails, the verification strategy can be adjusted, such as adding additional verification steps or requiring the user to provide higher-level authentication information, such as biometrics (fingerprint, facial recognition) or stronger authentication methods. The new payment verification information is then sent to the target account through a secure channel, such as SMS, email, or mobile application push notification. As with the sending of the first verification information, encryption technology should be used to ensure the secure transmission of information. To avoid attacks or automated attempts, the system should limit the number of times the user can retry the verification. If multiple authentication failures occur in a row, the system may temporarily lock the account and require the user to pass a higher level of authentication to unlock it. At the same time, detailed information about authentication failures can be recorded, including the time and reason of failure and the user's operation record. This data can be used for subsequent security analysis to help identify potential security threats or abnormal user behavior, thereby improving the system's security strategy.

[0052] Through this mechanism, the payment system can not only respond immediately and block unauthorized payment requests, but also give users the opportunity to re-verify, thereby protecting account security while ensuring a smooth and friendly user experience.

[0053] As an optional embodiment, the payment verification information includes verification information for verifying the account identity of the target account and verification information for verifying the payment environment.

[0054] Optionally, the payment verification information includes two key parts: verifying the account identity of the target account and verifying the payment environment. Such a design can comprehensively evaluate the security of the payment request. The verification of account identity information can generate a random one-time password and send it to the user via SMS, email or mobile application. The user needs to enter this password on the payment interface to prove his identity. Or a dynamic code based on time or event, which the user obtains through an authentication application installed on the mobile phone, such as Google Authenticator. Each generated verification code is unique. It can also be used such as fingerprint recognition, facial recognition or iris scanning. These verification information are directly associated with the user's physical characteristics, providing a highly secure verification method. The verification information of the payment link is used to ensure that the payment request is made in a secure environment to prevent the payment link from being used by unauthorized devices or malware. Common payment environment verification information includes: device fingerprint, checking whether the operation request comes from a known and trusted device. The device fingerprint can include the device's hardware ID, operating system type, browser information, etc. Geographic location verification, confirming the user's location through IP address or GPS positioning, and comparing it with the account holder's usual location to detect payment requests from abnormal locations. Network environment analysis: Check whether the user is making payments in a secure network environment, such as using an SSL-encrypted HTTPS connection or connecting to a known public WiFi.

[0055] The two parts of the payment verification information work together to effectively evaluate the security of the payment request and ensure that only legitimate account holders can complete the payment operation in a secure environment. This multi-dimensional verification mechanism not only enhances the security of the payment system, but also improves the ability to identify and defend against potential fraudulent activities.

[0056] As an optional embodiment, the target payment link becomes invalid after the target account completes the payment operation.

[0057] Optionally, the target payment link expires after the target account completes the payment operation, which can greatly improve the security of the payment link and prevent it from being used twice. Ensuring that the target payment link expires immediately after the target account completes the payment operation is one of the key security measures to prevent the payment link from being reused or illegally misused. You can also set a short validity period for the payment link. Once this time is exceeded, the link will automatically expire even if it has not been used. In addition, the validity of the link is also associated with a specific transaction status.

[0058] Through the above mechanism, the payment system can ensure that each payment link is only used legally once, greatly reducing the risks caused by the theft or reuse of payment links and improving security.

[0059] A specific embodiment is given below, wherein:

[0060] User triggers payment request: The user selects a product on the merchant website or app and submits an order, triggering a payment request.

[0061] Generate dynamic payment link: The system generates a unique, short-term payment link through an algorithm based on the user's device information, geographic location, access time and other factors.

[0062] Hide and display payment links: The system encrypts and obfuscates the generated payment links and hides them in a location that is not easily noticed by users. The payment link will only be activated and displayed to users when the user clicks the "Pay" button or meets other trigger conditions.

[0063] User verification and payment: After the user clicks the payment link, the system will perform multi-factor authentication to verify the user's identity and the security of the payment environment. If the verification is successful, the user is allowed to make the payment; if the verification fails, the payment request is rejected and the user is prompted to re-verify or contact customer service.

[0064] Link invalidation processing: After the user completes the payment operation, the system will immediately invalidate the payment link to prevent it from being used again. At the same time, the system will also record the use of the link and the payment results for subsequent audit and tracing.

[0065] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0066] Through the description of the above implementation methods, those skilled in the art can clearly understand that the payment link generation method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0067] According to an embodiment of the present invention, there is also provided a payment link generation device for implementing the payment link generation method described above. Figure 3is a structural block diagram of a device for generating a payment link according to an embodiment of the present invention. Figure 3 As shown, the payment link generation device includes: an acquisition module 32, a generation module 34, an encryption module 36 and a setting module 38. The payment link generation device is described below.

[0068] The acquisition module 32 is used to acquire the account information of the target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and geographic location of the target account.

[0069] The generating module 34 is connected to the acquiring module 32 and is used to generate an initial payment link based on the account information.

[0070] The encryption module 36 is connected to the generation module 34 and is used to encrypt the initial payment link to obtain the target payment link.

[0071] The setting module 38 is connected to the encryption module 36 and is used to load the target payment link at a preset position in the payment page to obtain a target payment page, wherein the target payment page is used to be displayed to the user end corresponding to the target account.

[0072] Optionally, the generation module is used to generate an initial payment link based on the account information, including: a generation unit, used to generate dynamic parameters based on the account information; an encryption unit, used to encrypt the dynamic parameters based on a preset encryption algorithm to obtain encrypted dynamic parameters; and a splicing unit, used to splice the encrypted dynamic parameters to a preset payment link in a preset format to obtain an initial payment link.

[0073] Optionally, before the acquisition module is used to acquire the account information of the target account, it includes: a receiving module, used to receive a payment request initiated based on the target account; and an acquisition module, used to acquire the account information of the target account based on the payment request.

[0074] Optionally, when an operation of clicking on a target payment link initiated based on a target account is received, a verification module is used to generate payment verification information; a sending module is used to send the payment verification information to the target account; and a determination module is used to determine that the target account is a safe account when a verification result returned by the target account is that the verification is passed, wherein a safe account represents an account that is allowed to perform payment operations.

[0075] Optionally, when the verification result returned by the target account is a verification failure, the rejection module is used to reject the payment request issued by the target account and generate payment verification information again and send it to the target account.

[0076] Optionally, the payment verification information includes verification information for verifying the account identity of the target account and verification information for verifying the payment environment.

[0077] Optionally, the target payment link becomes invalid after the target account completes the payment operation.

[0078] It should be noted that the acquisition module 32, the generation module 34, the encryption module 36 and the setting module 38 correspond to steps S202 to S208 in the embodiment, and the examples and application scenarios implemented by the multiple modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above embodiment. It should be noted that the above modules, as part of the device, can be run in the computer terminal 10 provided in the embodiment.

[0079] An embodiment of the present invention may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one network device among multiple network devices of a computer network. The computer device includes a memory and a processor.

[0080] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the method and device for generating payment links in the embodiments of the present invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, the above-mentioned method for generating payment links is realized. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include a memory remotely arranged relative to the processor, and these remote memories can be connected to the computer terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0081] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: obtain the account information of the target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account and the geographic location of the target account; based on the account information, generate an initial payment link; encrypt the initial payment link to obtain a target payment link; load the target payment link at a preset position in the payment page to obtain a target payment page, wherein the target payment page is used to display to the user end corresponding to the target account.

[0082] Optionally, the processor may also execute the program code of the following steps: generating an initial payment link based on the account information, including: generating dynamic parameters based on the account information; encrypting the dynamic parameters based on a preset encryption algorithm to obtain encrypted dynamic parameters; splicing the encrypted dynamic parameters to the preset payment link in a preset format to obtain an initial payment link.

[0083] Optionally, the processor may also execute program code of the following steps: before obtaining the account information of the target account, including: receiving a payment request initiated based on the target account; and obtaining the account information of the target account based on the payment request.

[0084] Optionally, the processor may also execute program code for the following steps: upon receiving an operation of clicking a target payment link initiated based on a target account, generating payment verification information; sending the payment verification information to the target account; and upon receiving a verification result returned by the target account indicating that the verification passed, determining that the target account is a safe account, wherein a safe account represents an account that is allowed to perform payment operations.

[0085] Optionally, the processor may also execute the following program code: when the verification result returned by the target account is a verification failure, reject the payment request issued by the target account and generate payment verification information again and send it to the target account.

[0086] Optionally, the processor may also execute program code of the following steps: the payment verification information includes verification information for verifying the account identity of the target account and verification information for verifying the payment environment.

[0087] Optionally, the processor may also execute program code of the following steps: the target payment link becomes invalid after the target account completes the payment operation.

[0088] According to an embodiment of the present invention, a method for generating a payment link is provided, by obtaining account information of a target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and geographic location of the target account; generating an initial payment link based on the account information; encrypting the initial payment link to obtain a target payment link; loading the target payment link at a preset position in a payment page to obtain a target payment page, wherein the target payment page is used to display to a user terminal corresponding to the target account, thereby achieving the purpose of multi-layer encryption of the payment link, thereby realizing the technical effect of improving the security of the payment link, and further solving the technical problem in the current payment system that the payment link is relatively fixed and easy to be stolen, resulting in insufficient security of the payment link.

[0089] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a non-volatile storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0090] The embodiment of the present invention further provides a non-volatile storage medium. Optionally, in this embodiment, the non-volatile storage medium can be used to store the program code executed by the payment link generation method provided in the above embodiment.

[0091] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0092] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining account information of the target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and the geographic location of the target account; generating an initial payment link based on the account information; encrypting the initial payment link to obtain a target payment link; loading the target payment link at a preset position in the payment page to obtain a target payment page, wherein the target payment page is used to be displayed to the user end corresponding to the target account.

[0093] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for executing the following steps: generating an initial payment link based on the account information, including: generating dynamic parameters based on the account information; encrypting the dynamic parameters based on a preset encryption algorithm to obtain encrypted dynamic parameters; splicing the encrypted dynamic parameters to a preset payment link in a preset format to obtain an initial payment link.

[0094] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for executing the following steps: before obtaining the account information of the target account, including: receiving a payment request initiated based on the target account; and obtaining the account information of the target account based on the payment request.

[0095] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for executing the following steps: upon receiving an operation of clicking a target payment link initiated based on a target account, generating payment verification information; sending the payment verification information to the target account; and upon receiving a verification result returned by the target account that the verification is passed, determining that the target account is a safe account, wherein a safe account represents an account that is allowed to perform payment operations.

[0096] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for executing the following steps: when the verification result returned by the target account is a verification failure, reject the payment request issued by the target account and generate payment verification information again and send it to the target account.

[0097] Optionally, in this embodiment, the non-volatile storage medium is configured to store program codes for executing the following steps: the payment verification information includes verification information for verifying the account identity of the target account and verification information for verifying the payment environment.

[0098] Optionally, in this embodiment, the non-volatile storage medium is configured to store program codes for executing the following steps: the target payment link becomes invalid after the target account completes the payment operation.

[0099] An embodiment of the present invention also provides a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can achieve: obtaining account information of a target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and geographic location of the target account; generating an initial payment link based on the account information; encrypting the initial payment link to obtain a target payment link; loading the target payment link at a preset position in the payment page to obtain a target payment page, wherein the target payment page is used to display to the user end corresponding to the target account.

[0100] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0101] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0102] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0103] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0104] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0105] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0106] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for generating a payment link, characterized in that: include: Acquire account information of a target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and a geographic location of the target account; Based on the account information, generate an initial payment link; Encrypting the initial payment link to obtain a target payment link; The target payment link is loaded at a preset position in the payment page to obtain a target payment page, wherein the target payment page is used to be displayed to the user end corresponding to the target account.

2. The method according to claim 1, characterized in that The generating an initial payment link based on the account information includes: Based on the account information, generating dynamic parameters; Encrypting the dynamic parameters based on a preset encryption algorithm to obtain encrypted dynamic parameters; The encrypted dynamic parameters are spliced ​​to the preset payment link according to a preset format to obtain the initial payment link.

3. The method according to claim 1, characterized in that Before obtaining the account information of the target account, the following steps are included: receiving a payment request initiated based on the target account; Based on the payment request, account information of the target account is obtained.

4. The method according to claim 1, characterized in that Also includes: generating payment verification information upon receiving an operation of clicking the target payment link initiated based on the target account; Sending the payment verification information to the target account; When the verification result returned by the target account indicates that the verification is passed, the target account is determined to be a safe account, wherein the safe account represents an account that is allowed to perform payment operations.

5. The method according to claim 4, characterized in that Also includes: When the verification result returned by the target account is a verification failure, the payment request issued by the target account is rejected and the payment verification information is generated again and sent to the target account.

6. The method according to claim 4, characterized in that The payment verification information includes verification information for verifying the account identity of the target account and verification information for verifying the payment environment.

7. The method according to any one of claims 1 to 6, characterized in that: The target payment link becomes invalid after the target account completes the payment operation.

8. A payment link generation device, characterized in that: include: an acquisition module, configured to acquire account information of a target account, wherein the account information includes at least one of the following: device information corresponding to the target account, access information of the target account, and a geographic location of the target account; A generation module, used to generate an initial payment link based on the account information; An encryption module, used to encrypt the initial payment link to obtain a target payment link; A setting module is used to load the target payment link at a preset position in the payment page to obtain a target payment page, wherein the target payment page is used to be displayed to the user terminal corresponding to the target account.

9. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein when the program is executed, the device where the non-volatile storage medium is located is controlled to execute the payment link generation method according to any one of claims 1 to 7.

10. A computer device, characterized in that: include: Memory and processor, The memory stores a computer program; The processor is used to execute the computer program stored in the memory, and when the computer program is run, the processor executes the payment link generation method according to any one of claims 1 to 7.

Images