QR code-based payment methods, devices, terminals, and software products

Abstract

This application provides a QR code-based payment method, device, terminal, and program product, relating to the field of big data processing technology. The method includes: obtaining the transaction status of each item owner based on an item owner payment information table; receiving a payment request sent by the current transaction user terminal by scanning the QR code of the target item owner; querying the transaction status of the target item owner based on the target item owner identifier in the payment request; and terminating the payment transaction corresponding to the payment request when the transaction status of the target item owner is determined to be non-transferable. By performing a horizontal comparison of the location information of historical transaction users to determine the transaction status of each item owner, and by promptly terminating the payment transaction when a payment request from the current transaction user for a target item owner is received and it is determined that the target item owner is non-transferable, payment security is improved.

Description

Technical Field

[0001] This application relates to the field of big data processing technology, and in particular to a QR code-based payment method, device, terminal, and program product. Background Technology

[0002] A QR code is a black and white image with specific geometric shapes arranged in a certain pattern on a plane. It is a key to information and data and has a wide range of applications in life, such as product anti-counterfeiting, data downloading, commodity transactions, and payments.

[0003] Currently, in QR code payment scenarios, the payer's APP typically scans the static QR code of the item owner to make payment. During payment, the payer's APP location information is sent to the acquiring institution, which then compares the payer's APP location with the location registered by the item owner to verify the legitimacy of the item owner.

[0004] However, because the location information registered by the owner of the goods is inaccurate, or the owner of the goods may frequently change their business location, comparing the location information of the payer's APP with the registered location information of the owner of the goods loses its verification meaning. As a result, it is impossible to determine whether the owner of the goods is abusing the static payment code, thus increasing the risk factor for users' payments. Summary of the Invention

[0005] This application provides a QR code-based payment method, device, terminal, and program product to solve the payment risk caused by inaccurate verification of the owner of the item due to the comparison between the payer's APP and the location of the owner of the item in the prior art.

[0006] Firstly, this application provides a QR code-based payment method applied to an acquiring institution's terminal, comprising: obtaining the transaction status of each item owner according to an item owner payment information table, wherein the item owner payment information table contains location information of historical transaction users associated with each item owner; receiving a payment request sent by the current transaction user terminal by scanning the QR code of a target item owner, wherein the payment request contains an identifier of the target item owner; querying the transaction status of the target item owner according to the identifier of the target item owner in the payment request, and terminating the payment transaction corresponding to the payment request when it is determined that the transaction status of the target item owner is untradeable.

[0007] Secondly, this application provides a QR code-based payment device, including: a transaction status acquisition module for the owner of goods, used to acquire the transaction status of each owner of goods according to the payment information table of the owner of goods, wherein the payment information table of the owner of goods contains the location information of the historical transaction users associated with each owner of goods.

[0008] The payment request receiving module is used to receive a payment request sent by the current transaction user terminal by scanning the QR code of the owner of the target item, wherein the payment request contains the identifier of the owner of the target item;

[0009] The payment transaction termination module is used to query the transaction status of the owner of the target item based on the owner identifier of the target item in the payment request. When it is determined that the transaction status of the owner of the target item is not tradable, the payment transaction corresponding to the payment request is terminated.

[0010] Thirdly, this application provides an acquiring institution terminal, including: a processor, and a memory communicatively connected to the processor;

[0011] The memory stores computer-executed instructions;

[0012] The processor executes computer execution instructions stored in the memory to implement the method described in this application.

[0013] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in this application.

[0014] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in this application.

[0015] The QR code-based payment method, device, terminal, and program products provided in this application determine the transaction status of each item owner by horizontally comparing the location information of historical transaction users associated with each item owner in the item owner payment information table. Even if the item owner changes location or the registered location is inaccurate, the location information of historical transaction users is obtained when they send payment requests to the item owner and is therefore authentic and valid. Thus, the transaction status of each item owner determined based on the location information of historical transaction users is more accurate. Therefore, when a payment request is received from the current transaction user for a target item owner and it is determined that the target item owner's transaction status is not tradable, it indicates that there is a transaction risk with the current item owner's QR code. By terminating the payment transaction in a timely manner, the security of the user's QR code payment is improved. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] Figure 1 The process of the QR code-based payment method provided in the embodiments of this application Figure 1 ;

[0018] Figure 2 The process of the QR code-based payment method provided in the embodiments of this application Figure 2 ;

[0019] Figure 3 The process of the QR code-based payment method provided in the embodiments of this application Figure 3 ;

[0020] Figure 4 The process of the QR code-based payment method provided in the embodiments of this application Figure 4 ;

[0021] Figure 5 A schematic diagram of the structure of a QR code-based payment device provided in an embodiment of this application;

[0022] Figure 6 This is a schematic diagram of the acquiring terminal provided in an embodiment of this application.

[0023] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0025] Terminology Explanation:

[0026] Acquiring institutions: Clearing member units that have agreements with the owners of goods or provide services to cardholders and participate in the exchange directly or indirectly based on transaction documents (including paper documents).

[0027] Owner of the goods: Individuals, companies, or other organizations that have signed agreements with acquiring institutions and accept bank cards.

[0028] Target item owner's QR code: This is a URL-based QR code used in the active scanning scenario, usually placed as a QR code sign at the store where the item belongs.

[0029] In existing technologies, QR code payment scenarios typically involve the payer's app scanning a static QR code belonging to the item's owner to make payment. During payment, the payer's app's location information is sent to the acquiring institution, which then compares this location with the item's registered location to verify the item's legitimacy. However, because the item's registered location information is often inaccurate, or the item's owner may frequently change their business location, comparing the payer's app's location with the item's registered location becomes meaningless. This makes it impossible to determine if the item's owner is abusing the static QR code, thus increasing the risk for users.

[0030] To address the aforementioned technical problems, this application proposes the following technical concept: Obtaining a payment information table for the item owner, wherein the table contains location information of historical transaction users associated with each item owner; conducting a risk assessment of the item owner based on the payment information table to obtain the transaction status of each item owner, including whether the transaction is untradeable or permitted; receiving a payment request sent by the current transaction user's terminal by scanning the target item owner's QR code, wherein the payment request contains the target item owner's identifier; querying the target item owner's transaction status based on the target item owner's identifier in the payment request, and terminating the payment transaction corresponding to the payment request when the target item owner's transaction status is determined to be untradeable. This solves the payment risk problem caused by inaccurate item owner verification due to comparing the payer's APP with the item owner's location in existing technologies.

[0031] The technical solution of this application and how it solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings. The acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0032] Figure 1 The first step in illustrating the QR code-based payment method provided in this application is as follows. Figure 1 As shown, the method includes the following steps:

[0033] Step S101: Obtain the transaction status of each item owner based on the item owner payment information table.

[0034] The payment information table for the item owner contains the location information of historical transaction users associated with each item owner.

[0035] Optionally, the transaction status of each item owner can be obtained based on the item owner payment information table, including: obtaining the item owner payment information table; conducting a risk assessment of the item owner based on the item owner payment information table, and obtaining the transaction status of each item owner, wherein the transaction status includes whether the transaction is not allowed or is permitted.

[0036] Optionally, obtaining the item owner payment information table includes: receiving historical payment requests sent by each historical transaction user terminal, wherein the historical payment requests contain the location information of the historical transaction user and the item owner corresponding to the transaction; and obtaining the item owner payment information table based on the historical payment requests.

[0037] Optionally, the payment information table of the item owner is obtained based on historical payment requests, including: identifying historical transaction users who have transaction relationships with each item owner based on historical payment requests, and treating the historical users with transaction relationships as historical transaction users associated with each item owner; binding the location information of each item owner with the associated historical transaction users to construct the item owner payment information table, wherein the item owner payment information table marks the transaction time of the historical transaction users.

[0038] Specifically, in this embodiment, the acquiring institution's terminal stores a payment information table for the item's owner, which includes the location information of historical transaction users associated with each item's owner. The acquiring institution's terminal obtains this payment information table as follows: when a historical transaction user's terminal scans the QR code of a locally registered item's owner, it obtains the item's owner identifier and order number from the scanned QR code. The historical transaction user's terminal then displays an amount input page. Upon receiving the amount entered by the historical transaction user, it obtains the historical transaction user's card number and location information, and generates a historical payment request, sending it to the acquiring institution's terminal. Therefore, the historical payment request includes the historical transaction user's location information and the corresponding item's owner. The historical transaction user's location information can be obtained through location services provided by the app used to make the payment.

[0039] In this system, the acquiring institution's terminal identifies historical transaction users with existing transaction relationships with each item owner based on the acquired historical payment requests. These historical users with existing transaction relationships are then designated as historical users associated with each item owner. A payment information table for item owners is constructed by binding the location information of each item owner with that of their associated historical transaction users. For example, if it is determined that users 1, 2, 3, and 4 have all made payments by scanning the QR code of item owner X, then users 1, 2, 3, and 4 are identified as historical transaction users associated with item owner X. The location information of item owner X is then bound to that of users 1, 2, 3, and 4. This implementation uses item owner X as an example; the method for determining associated historical transaction users for other locally registered item owners is largely the same and will not be elaborated upon in this implementation. Table 1 below illustrates the constructed payment information table for item owners.

[0040] Table 1

[0041]

[0042] The payment information table for the item owner marks the transaction time of the historical transaction user. Due to space limitations, Table 1 only uses the item owner X as an example for explanation.

[0043] Figure 2 The process of the QR code-based payment method provided in the embodiments of this application Figure 2 ,process Figure 2 The main focus is on a detailed explanation of step S101, including:

[0044] Step S1011: Obtain the payment information table of the item owner.

[0045] Step S1012: Determine the daily risk status of each item owner based on the item owner payment information table.

[0046] Specifically, this implementation determines the daily risk status of each item owner based on the item owner payment information table, where risk status includes risk or security. Furthermore, in determining the daily risk status of each item owner, the location information of historical transaction users associated with each item owner is compared horizontally. The daily risk status of the item owner is obtained based on the comparison results of the location information of historical transaction users associated with the same item owner. Because the daily risk status of the item owner is no longer verified based on the location information at the time of item owner registration, but instead uses the more accurate location information of associated historical transaction users, the obtained risk status of the item owner is more accurate.

[0047] Step S1013: Determine whether the number of times the owner of the item has been identified as a risk within a specified time range exceeds the preset number. If yes, proceed to step S1023; otherwise, proceed to step S1024.

[0048] Specifically, this implementation method obtains the number of times the item owner is identified as risky within a specified time range, and determines the item owner's transaction status by comparing the number of times identified as risky with a preset number. For example, the item owner X is identified as risky seven times within seven days, while the preset number can be six.

[0049] The preset number of times can be related to a specified time range. For example, the preset number of times can be the same as the number of days included in the specified time range, or the preset number of times can be one less than the number of days included in the specified time range. Of course, this embodiment is only an example and does not limit the specific method of determining the preset number of times. The preset number of times can be set according to the actual needs of payment security.

[0050] Step S1014: Determine that the transaction status of the item's owner is non-tradable.

[0051] Specifically, if the number of times the owner of an item is identified as at risk exceeds a preset number within a specified time frame, for example, if the owner of an item X is identified as at risk seven times within seven days, while the preset number can be six, then the transaction status of the owner of an item X is determined to be untradeable.

[0052] Step S1015: Determine the transaction status of the item owner as permissible.

[0053] Specifically, if the number of times the item owner X is identified as risky within a specified time frame does not exceed a preset number, for example, if the item owner X is identified as risky once within seven days, and the preset number can be 6, then the transaction status of the item owner X is determined to be allowed to be traded.

[0054] Specifically, in this embodiment, after determining the transaction status of each item's owner, the obtained transaction status of each item will be recorded and saved to the item owner's transaction status list. Table 2 below shows an example of the item owner's transaction status list:

[0055] Table 2

[0056] Ownership identification Transaction status X Tradeable Y Allow transactions Z Allow transactions … …

[0057] Step S102: Receive the payment request sent by the current transaction user terminal by scanning the QR code of the owner of the target item.

[0058] Specifically, when the current transaction user terminal scans the QR code of the target item's owner, it obtains information such as the target item's owner identifier and order number through the scanned QR code information. The current transaction user terminal will display an amount input page. When it receives the amount entered by the current transaction user, it will obtain the current transaction user's card number and location information, and generate a payment request to send to the acquiring institution's terminal. Therefore, the payment request includes the target item's owner identifier.

[0059] Optionally, the payment request may also include the location information of the current transaction user. After receiving the payment request sent by the current transaction user's terminal by scanning the QR code of the owner of the target item, the request may also include updating the payment information table of the owner of the item based on the location information of the current transaction user.

[0060] Specifically, since the payment request includes the current transaction user's location information, the acquiring institution's terminal will update the item owner payment information table shown in Table 1 based on the current transaction user's location information when it receives the payment request. For example, if the current transaction user is User 5, and on August 15, 2021, they sent a transaction request to the acquiring institution's terminal by scanning the item owner X's QR code and completed the transaction with item owner X, then the current transaction user's location information can be obtained to update the item owner payment information table shown in Table 1. Table 2 below shows an illustration of the updated item owner payment information table:

[0061] Table 2

[0062]

[0063] Step S103: Query the transaction status of the target item owner based on the target item owner identifier in the payment request. When it is determined that the transaction status of the target item owner is not tradable, terminate the payment transaction corresponding to the payment request.

[0064] Specifically, when the acquiring institution's terminal receives a payment request from the current transaction user's terminal, it queries the transaction status of the target owner based on the item owner identifier contained in the payment request. For example, if the item owner identifier is determined to be X, the institution queries the transaction status list of item owners shown in Table 2. If the transaction status of item owner X is determined to be untradeable, the payment transaction corresponding to the payment request will be terminated. By terminating the payment transaction, the payment security of the current transaction user can be guaranteed, and financial loss can be avoided.

[0065] Optionally, the payment request may also include an order number, payment amount, and the current transaction user's payment card number. The method further includes: when it is determined that the transaction status of the target item's owner is allowed, generating a transaction message based on the order number, payment amount, and current transaction user's payment card number and sending it to the user's payment institution terminal, so that the user's payment institution terminal updates the funds in the current transaction user's payment card number according to the payment amount based on the transaction message, and generating a response message and sending it to the acquiring institution terminal; receiving the response message, obtaining the target item's owner's payment card number based on the target item's owner identifier based on the response message, and updating the funds in the target item's owner's payment card number according to the payment amount.

[0066] Optionally, after updating the funds in the target item's owner's bank card number according to the payment amount, the method further includes: generating a transaction completion instruction based on the updated funds in the target item's owner's bank card number; and sending the transaction completion instruction to the current transaction user's terminal so that the current transaction user's terminal can display the transaction completion instruction.

[0067] Specifically, when the acquiring institution's terminal receives a payment request from the current transaction user's terminal, it checks the transaction status of the target owner based on the item owner identifier included in the payment request. If the transaction is approved, the acquiring institution's terminal interacts with the user's payment institution's terminal, increasing the funds in the target item owner's receiving card number according to the payment amount and decreasing the funds in the user's payment card number accordingly to complete the payment transaction. Furthermore, after updating the funds in the target item owner's receiving card number, the acquiring institution's terminal generates a transaction completion indication, which is sent to the current transaction user's terminal for display, allowing the user to obtain the real-time payment status of the transaction.

[0068] In this embodiment, the transaction status of each item owner in the item owner payment information table is determined by horizontally comparing the location information of historical transaction users associated with each item owner. Even if the location of each item owner changes or the registered location is inaccurate, the location information of historical transaction users is obtained when they send payment requests to the item owner and is therefore authentic and valid. Thus, the transaction status of each item owner determined based on the location information of historical transaction users is more accurate. Therefore, when a payment request is received from the current transaction user for the target item owner and it is determined that the transaction status of the target item owner is not tradable, it indicates that there is a transaction risk with the current item owner's QR code. By terminating the payment transaction in a timely manner, the security of user QR code payment is improved.

[0069] like Figure 3 The diagram shows the process of a QR code-based payment method provided in this embodiment. Figure 3 .like Figure 3 As shown, the process Figure 3 The main focus is on a detailed explanation of step S1021, including:

[0070] Step S201: Determine the distance difference of the location information of the historical transaction users associated with each item owner on each day based on the item owner payment information table.

[0071] Specifically, in this embodiment, when determining the daily risk status of each item owner based on the item owner's payment information, the determination is made by making a horizontal comparison based on the location information of the historical transaction users associated with each item owner, without referring to the location information of the item owner at the time of registration, thereby making the obtained risk status of the item owner more accurate.

[0072] In one specific implementation, if users 1, 2, 3, and 4 all scan the QR code of the item's owner, X, to make a payment transaction on the same day using the app, then the location information of each historical transaction user, obtained through the app's location tracking, is retrieved, and the distance difference between their locations is calculated. For example, the distance difference between users 1 and 2 is 510 km, between users 1 and 3 is 505 km, between users 1 and 4 is 450 km, between users 2 and 3 is 502 km, between users 2 and 4 is 520 km, and between users 3 and 4 is 560 km. This implementation is merely illustrative and does not limit the number of historical transaction users associated with each item's owner.

[0073] Step S202: Determine whether the distance difference exceeding a specified percentage each day is greater than the preset distance. If yes, proceed to step S203; otherwise, proceed to step S204.

[0074] In this embodiment, the preset distance can be 500 kilometers, and the specified percentage can be 80%. Of course, in practical applications, the specific values ​​of the specified percentage and the preset distance can be set according to actual safety requirements. Therefore, this embodiment specifically determines whether the distance difference exceeds 500 kilometers for more than 80% of the days.

[0075] Step S203: Determine the risk status of the party owning the item on that day as risk.

[0076] Referring to the distance differences obtained in the above example, the distance differences between historical transaction users associated with the item owner X on the same day—User 1, User 2, User 3, and User 4—are 510 km, 505 km, 450 km, 502 km, 520 km, and 560 km, respectively. Calculations show that 83% of the distance differences exceed 500 km each day, thus classifying the risk status of the item owner X on that day as risky.

[0077] Step S204: Determine that the risk status of the owner of the item on that day is safe.

[0078] If calculations determine that less than 80% of the distance differences exceed 500 kilometers each day, then the risk status of the party owning the goods on that day is considered safe.

[0079] like Figure 4 The diagram shows the flow of a QR code-based payment method provided in this embodiment. Figure 4 .like Figure 4 ,process Figure 4After terminating the payment transaction corresponding to the payment request, the process also includes triggering the generation of alarm information and sending the alarm information to the current transaction user's terminal so that the current transaction user's terminal can display the alarm information. The methods include:

[0080] Step S301: Obtain the transaction status of each item owner based on the item owner payment information table.

[0081] Optionally, the transaction status of each item owner can be obtained based on the item owner payment information table, including: obtaining the item owner payment information table; conducting an item owner risk assessment based on the item owner payment information table, and obtaining the transaction status of each item owner, wherein the transaction status includes whether the transaction is not allowed or is permitted.

[0082] Optionally, obtaining the item owner payment information table includes: receiving historical payment requests sent by each historical transaction user terminal, wherein the historical payment requests contain the location information of the historical transaction user and the item owner corresponding to the transaction; and obtaining the item owner payment information table based on the historical payment requests.

[0083] Step S302: Receive the payment request sent by the current transaction user terminal by scanning the QR code of the owner of the target item.

[0084] Step S303: Query the transaction status of the target item owner based on the target item owner identifier in the payment request. If it is determined that the transaction status of the target item owner is not tradable, terminate the payment transaction corresponding to the payment request.

[0085] Step S304: Trigger the generation of alarm information and send the alarm information to the current trading user terminal so that the current trading user terminal can display the alarm information.

[0086] Specifically, in this embodiment, after the payment transaction corresponding to the payment request is terminated, an alarm message will be generated, such as "The current transaction is at risk, and the payment transaction has been terminated." The acquiring institution's terminal will send the generated alarm message to the current transaction user's terminal so that the current transaction user's terminal can display the alarm message. The alarm message can be displayed in text or sound form; this embodiment does not limit the specific display method of the alarm message on the current transaction user's terminal. By displaying the alarm message in sound or text form, the current transaction user can promptly obtain the payment status of the current transaction.

[0087] Figure 5 This is a schematic diagram of the structure of a QR code-based payment device provided in an embodiment of this application. Figure 5As shown, the activity resource allocation device includes: a transaction status acquisition module 510 for the item owner, a payment request receiving module 520, and a payment transaction termination module 530.

[0088] The transaction status acquisition module 510 of the item owner is used to obtain the transaction status of each item owner according to the item owner payment information table, wherein the item owner payment information table contains the location information of the historical transaction users associated with each item owner.

[0089] The payment request receiving module 520 is used to receive the payment request sent by the current transaction user terminal by scanning the QR code of the owner of the target item, wherein the payment request contains the identifier of the owner of the target item;

[0090] The payment transaction termination module 530 is used to query the transaction status of the target item owner based on the target item owner identifier in the payment request. When it is determined that the transaction status of the target item owner is not tradable, the payment transaction corresponding to the payment request is terminated.

[0091] The module for obtaining the transaction status of the item's owner includes:

[0092] The item owner payment information table acquisition submodule is used to acquire the item owner payment information table;

[0093] The item owner transaction status acquisition submodule is used to perform risk assessment on the item owner based on the item owner payment information table and acquire the transaction status of each item owner, wherein the transaction status includes whether the item is not tradable or is tradable.

[0094] Optionally, the submodule for obtaining the payment information table of the item owner includes:

[0095] The historical payment request receiving unit is used to receive historical payment requests sent by each historical transaction user terminal. The historical payment request includes the location information of the historical transaction user and the owner of the item corresponding to the transaction.

[0096] The item owner payment information table acquisition unit is used to obtain the item owner payment information table based on historical payment requests.

[0097] Optionally, the item owner payment information table acquisition unit is used to determine the historical transaction users who have transaction relationships with each item owner based on historical payment requests, and to regard the historical users who have transaction relationships as the historical transaction users associated with each item owner;

[0098] The location information of each item owner and the associated historical transaction users are bound together to construct an item owner payment information table, which marks the transaction time of the historical transaction users.

[0099] Optional, the submodule for obtaining the transaction status of the item's owner includes:

[0100] The risk status determination unit is used to determine the daily risk status of each item owner based on the item owner payment information table, where risk status includes risk or safety.

[0101] The item owner's transaction status acquisition unit is used to determine whether the number of times the item owner has been identified as risk within a specified time range exceeds a preset number. If so, the item owner's transaction status is determined to be untradeable; otherwise, the item owner's transaction status is determined to be tradeable.

[0102] Optionally, a risk status determination unit is used to determine the distance difference of the location information of the historical transaction users associated with each item owner on a daily basis, based on the item owner payment information table, wherein the number of distance differences is at least three.

[0103] Determine if the distance difference exceeds a specified percentage each day and is greater than a preset distance. If so, determine that the risk status of the item owner for that day is risky; otherwise, determine that the risk status of the item owner for that day is safe.

[0104] Optionally, the payment request may also include an order number, payment amount, and the current transaction user's payment card number. The device may also include a transaction module, which, when the transaction status of the owner of the target item is determined to be allowed, generates a transaction message based on the order number, payment amount, and current transaction user's payment card number and sends it to the user's payment institution terminal, so that the user's payment institution terminal updates the funds of the current transaction user's payment card number according to the payment amount based on the transaction message, and generates a response message and sends it to the acquiring institution terminal.

[0105] Receive the response message, obtain the target item owner's payment card number based on the target item owner's identifier in the response message, and update the funds in the target item owner's payment card number according to the payment amount.

[0106] Optionally, the payment request may also include the location information of the current transaction user, and the device may also include a payment information table update module for the item owner, used to update the payment information table for the item owner based on the location information of the current transaction user.

[0107] Optionally, the device also includes an alarm information display module for triggering the generation of alarm information;

[0108] The alarm information is sent to the current trading user's terminal so that the current trading user's terminal can display the alarm information.

[0109] Optionally, the device also includes a transaction completion indication display module, used to generate a transaction completion indication based on the fund update result of the receiving card number of the target item's owner;

[0110] Send the transaction completion instruction to the current transaction user's terminal so that the current transaction user's terminal can display the transaction completion instruction.

[0111] The QR code-based payment device provided in this application embodiment can be used to execute the technical solution of the QR code-based payment method in the above embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0112] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software through processing element calls; they can be fully implemented in hardware; or some modules can be implemented through processing element calls in software, while others are implemented in hardware. Additionally, these modules can be integrated together or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0113] Figure 6 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0114] like Figure 6As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0115] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0116] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as QR code-based payment methods.

[0117] In some embodiments, the QR code-based payment method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the QR code-based payment method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the QR code-based payment method by any other suitable means (e.g., by means of firmware).

[0118] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0119] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0120] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0121] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0122] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0123] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0124] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the QR code-based payment method provided in any embodiment of this application.

[0125] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0126] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A two-dimensional code-based payment method, characterized by, The application is applied to a terminal of an acquirer, and comprises: According to the payment information table of the article ownership party, the transaction status of each article ownership party is obtained, wherein the payment information table of the article ownership party contains the location information of the historical transaction user associated with each article ownership party; The payment request sent by the current transaction user terminal by scanning the two-dimensional code of the target article ownership party is received, wherein the payment request contains the identification of the target article ownership party; According to the target article ownership party identification in the payment request, the transaction status of the target article ownership party is queried, and when it is determined that the transaction status of the target article ownership party is not tradable, the payment transaction corresponding to the payment request is terminated; According to the payment information table of the article ownership party, the transaction status of each article ownership party is obtained, comprising: obtaining the payment information table of the article ownership party; according to the payment information table of the article ownership party, the transaction status of each article ownership party is obtained, wherein the transaction status comprises non-tradable or tradable; The payment information table of the article ownership party is obtained, comprising: receiving the historical payment request sent by each historical transaction user terminal, wherein the historical payment request contains the location information of the historical transaction user and the article ownership party corresponding to the transaction; and the payment information table of the article ownership party is obtained according to the historical payment request; According to the historical payment request, the historical transaction user in a transaction relationship with each article ownership party is determined, and the historical transaction user in a transaction relationship is associated with each article ownership party; the location information of each article ownership party and the associated historical transaction user is bound to construct the payment information table of the article ownership party, wherein the payment information table of the article ownership party is marked with the transaction time of the historical transaction user.

2. The method of claim 1, wherein, According to the payment information table of the article ownership party, the transaction status of each article ownership party is obtained, comprising: According to the payment information table of the article ownership party, the risk status of each article ownership party per day is determined, wherein the risk status comprises risk or safety; Determine whether the number of times that the article ownership party is determined to be risky within a specified time range exceeds a preset number, if yes, determine that the transaction status of the article ownership party is not tradable, otherwise, determine that the transaction status of the article ownership party is tradable.

3. The method of claim 2, wherein, According to the payment information table of the article ownership party, the risk status of each article ownership party per day is determined, comprising: According to the payment information table of the article ownership party, the distance difference of the location information of the historical transaction user associated with each article ownership party per day is determined, wherein the number of distance differences is at least three; Determine whether more than a specified proportion of distance differences per day are greater than a preset distance, if yes, determine that the risk status of the article ownership party per day is risk, otherwise, determine that the risk status of the article ownership party per day is safety.

4. The method of claim 1, wherein, The payment request also includes an order number, a payment amount and a current transaction user payment card number, and the method further comprises: When it is determined that the transaction condition of the target article owner is a permitted transaction, a transaction message is generated according to the order number, the payment amount, and the current transaction user payment card number and sent to a user payment institution terminal, so that the user payment institution terminal updates the funds of the current transaction user payment card number according to the payment amount based on the transaction message, and generates a response message and sends it to the acquirer institution terminal; The response message is received, and the target article owner payment card number is obtained based on the target article owner identifier based on the response message, and the funds of the target article owner payment card number are updated according to the payment amount.

5. The method of claim 1, wherein, The payment request also includes the location information of the current transaction user, After receiving the payment request sent by the current transaction user terminal by scanning the target article owner two-dimensional code, the following is further included: Update the article owner payment information table according to the location information of the current transaction user.

6. The method of claim 1, wherein, After terminating the payment transaction corresponding to the payment request, the following is further included: Trigger the generation of an alarm information; Send the alarm information to the current transaction user terminal, so that the current transaction user terminal displays the alarm information.

7. The method of claim 4, wherein, After updating the funds of the target article owner payment card number according to the payment amount, the following is further included: Generate a transaction completion instruction according to the fund update result of the target article owner payment card number; Send the transaction completion instruction to the current transaction user terminal, so that the current transaction user terminal displays the transaction completion instruction.

8. A two-dimensional code-based payment device, characterized by comprising: It includes: An article owner transaction condition acquisition module for acquiring the transaction conditions of each article owner based on an article owner payment information table, wherein the article owner payment information table contains the location information of each article owner associated with the historical transaction user; A payment request receiving module for receiving a payment request sent by a current transaction user terminal by scanning a target article owner two-dimensional code, wherein the payment request contains a target article owner identifier; A payment transaction termination module for querying the transaction condition of the target article owner according to the target article owner identifier in the payment request, and terminating the payment transaction corresponding to the payment request when it is determined that the transaction condition of the target article owner is not a transaction; The article owner transaction condition acquisition module includes an article owner payment information table acquisition submodule for acquiring the article owner payment information table; An article owner transaction condition acquisition submodule for performing article owner risk assessment based on the article owner payment information table to acquire the transaction condition of each article owner, wherein the transaction condition includes non-transaction or permitted transaction; The article owner payment information table acquisition submodule is configured to receive historical payment requests sent by each historical transaction user terminal, wherein the historical payment request contains the location information of the historical transaction user and the article owner corresponding to the transaction; and acquire the article owner payment information table based on the historical payment request. The article ownership payment information table obtaining submodule comprises a historical transaction user extracting submodule, configured to determine historical transaction users having a transaction relationship with each article ownership according to the historical payment request, and take the historical transaction users having the transaction relationship as historical transaction users associated with each article ownership; An article ownership payment information table constructing submodule is configured to bind each article ownership and location information of the associated historical transaction users to construct the article ownership payment information table, wherein the article ownership payment information table is marked with transaction time of the historical transaction users.

9. An acquirer structure terminal, characterized by, Comprise: A processor, and a memory connected with the processor in communication; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to implement the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1-7.

11. A computer program product, characterised in that, A computer program is executed by the processor to implement the method of any one of claims 1-7.

Images