Offline code-based payment method and apparatus

Abstract

The application provides an offline code-based payment method and device, and relates to the technical field of information security. The method comprises the following steps: scanning a payment code displayed by a terminal device to obtain payment request information, wherein the payment request information comprises a first synchronization string, a first timestamp and a first user account; outputting an account confirmation signal based on the payment request information; scanning a payment confirmation code displayed by the terminal device to obtain payment confirmation information, wherein the payment confirmation code is generated by the terminal device based on the account confirmation signal, and the payment confirmation information comprises a second synchronization string, a second timestamp and a second user account; and generating an offline order in the case that the payment request information and the payment confirmation information match, so that a backend server deducts the account bound to the terminal device based on the offline order. The above steps can improve the security in the offline payment process.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a payment method and apparatus based on offline codes. Background Technology

[0002] Image code payment is convenient and fast, making it the preferred choice for many citizens for transactions. However, current image codes are generally online, and the network environment significantly affects the speed at which the terminal device generates the image code. In poor network conditions, the image code may not display, making scanning and payment impossible. This is especially true when using public transportation, where poor network conditions often prevent the terminal device from displaying the image code for payment, thus disrupting citizens' daily travel. Offline image codes, on the other hand, are unaffected by network conditions and can be generated normally even in poor network environments.

[0003] However, most offline image code payment solutions rely on the scanning terminal to verify the legitimacy of the image code, and cannot interact with the code-generating terminal. This can lead to insecure payment situations such as fraudulent or repeated transactions. Therefore, the security of image codes in offline payment processes is relatively low under current technology. Summary of the Invention

[0004] This application provides a payment method and apparatus based on offline codes, which can improve the security of graphic codes during offline payment.

[0005] Firstly, embodiments of this application provide a payment method based on offline codes, applied to a QR code scanning device, the method comprising:

[0006] Scan the payment code displayed on the terminal device to obtain payment request information, which includes a first synchronization string, a first timestamp, and a first user account;

[0007] Based on the payment request information, an account confirmation signal is output;

[0008] Scan the payment confirmation code displayed on the terminal device to obtain payment confirmation information. The payment confirmation code is generated by the terminal device based on the account confirmation signal. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account.

[0009] If the payment request information and the payment confirmation information match, an offline order is generated so that the backend server can deduct the payment from the account bound to the terminal device based on the offline order.

[0010] Secondly, embodiments of this application provide a payment method based on an offline code, applied to a terminal device, the method comprising:

[0011] A payment code is generated based on payment request information, which includes a first synchronization string, a first timestamp, and a first user account.

[0012] Display the payment code to allow the scanning device to scan it;

[0013] Detect the account confirmation signal output by the scanning device to obtain account status information;

[0014] If the account status information is normal, a payment confirmation code is generated based on the payment confirmation information, which includes a second synchronization string, a second timestamp, and a second user account.

[0015] Display the payment confirmation code to enable the scanning device to scan it.

[0016] Thirdly, embodiments of this application provide a payment device based on an offline code, the device comprising:

[0017] The first scanning module is used to scan the payment code displayed on the terminal device to obtain payment request information, which includes a first synchronization string, a first timestamp, and a first user account.

[0018] The signal light module is used to output an account confirmation signal based on the payment request information;

[0019] The second scanning module is used to scan the payment confirmation code displayed on the terminal device to obtain payment confirmation information. The payment confirmation code is generated by the terminal device based on the account confirmation signal. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account.

[0020] The matching module is used to generate an offline order when the payment request information and the payment confirmation information match, so that the backend server can deduct the payment from the account bound to the terminal device based on the offline order.

[0021] Fourthly, embodiments of this application provide a payment device based on an offline code, the device comprising:

[0022] The first generation module is used to generate a payment code based on payment request information, wherein the payment request information includes a first synchronization string, a first timestamp, and a first user account.

[0023] The first display module is used to display the payment code so that the scanning device can scan it;

[0024] The detection module is used to detect the account confirmation signal output by the scanning device and obtain account status information;

[0025] The second generation module is used to generate a payment confirmation code based on the payment confirmation information when the account status information is in a normal state. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account.

[0026] The second display module is used to display the payment confirmation code so that the scanning device can scan it.

[0027] Fifthly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0028] When the processor executes computer program instructions, it implements the offline code-based payment method as described in any of the embodiments of the first or second aspect.

[0029] Sixthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the offline code-based payment method as described in any of the embodiments of the first or second aspect.

[0030] In a seventh aspect, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform an offline code-based payment method as described in any of the embodiments of the first or second aspect above.

[0031] The offline code-based payment method and apparatus in this application embodiment, through two verifications between the scanning device and the terminal device based on the payment code and payment confirmation code, enables the scanning device to verify the identity of the terminal device twice. By comparing the payment request information and payment confirmation information during the two verification processes, it verifies whether it is the same terminal device, avoiding insecure payment situations such as fraudulent or duplicate transactions. This ensures the authenticity and uniqueness of the terminal device's payment information and avoids the security issues that cannot be guaranteed by the scanning device's one-way verification. Furthermore, by recording offline orders between the terminal device and the scanning device, offline payments can be realized for users, improving the security of the payment code during offline payments. Attached Figure Description

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

[0033] Figure 1 This is a flowchart illustrating a payment method based on an offline code provided in one embodiment of this application;

[0034] Figure 2 This is a flowchart illustrating an example of a payment method based on an offline code provided in one embodiment of this application;

[0035] Figure 3 This is a flowchart illustrating another example of a payment method based on an offline code provided in one embodiment of this application;

[0036] Figure 4 This is a flowchart illustrating a payment method based on an offline code, provided in yet another embodiment of this application.

[0037] Figure 5 This is a schematic diagram of the structure of a payment device based on an offline code according to an embodiment of this application;

[0038] Figure 6 This is a schematic diagram of the structure of a payment device based on an offline code provided in another embodiment of this application;

[0039] Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0040] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0041] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

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

[0043] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant national laws and regulations.

[0044] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the related technologies:

[0045] Image code payment is convenient and fast, making it the preferred choice for many citizens for transactions. However, current image codes are generally online, and network conditions significantly affect the speed at which terminal devices generate the image codes. In poor network environments, the image code may not display, preventing scanning and payment, thus impacting citizens' daily lives. Offline image codes, on the other hand, are unaffected by network conditions and can be generated normally even with poor network connectivity.

[0046] Typical offline image code solutions rely on the scanning terminal to verify the legitimacy of the image code, and cannot interact with the code-generating terminal. This can lead to insecure payment situations such as fraudulent or repeated transactions. Therefore, existing technologies offer relatively low security for image codes in offline payment processes.

[0047] To address the problems of the prior art, this application provides a payment method and apparatus based on offline codes. The offline code-based payment method provided in this application will be described first.

[0048] Figure 1 A schematic flowchart of an offline code-based payment method according to an embodiment of this application is shown. Figure 1 As shown, the method may specifically include the following steps:

[0049] Step 101: The terminal device generates a payment code based on the payment request information;

[0050] Step 102: The terminal device displays the payment code for the scanning device to scan.

[0051] Step 103: The scanning device scans the payment code displayed on the terminal device to obtain payment request information;

[0052] In this embodiment, the payment code may include a QR code or a barcode, or it may be a graphic code composed of other forms, such as a combination of dots and lines, or letters, Chinese characters, etc. This application does not impose any restrictions.

[0053] The payment request information includes a first synchronization string, a first timestamp, and a first user account. The first synchronization string is a numeric string with a value range of [000, 998]. The first timestamp is the real-time time when the terminal device generates the payment code. The first user account is the identity account of the terminal device when it generates the payment code, and it corresponds one-to-one with the terminal device.

[0054] The scanning device can be a QR code payment device, such as a POS terminal with QR code scanning functionality. Similarly, the terminal device can be a terminal payment device, such as a mobile phone or a display device with payment functionality. When making a payment, the user can generate and display a payment code on their mobile phone, allowing the payee to scan the code at the POS terminal to obtain the payment request information.

[0055] Alternatively, the scanning device can also be a QR code payment device, such as a QR code scanner installed on public transportation equipment. Correspondingly, the terminal device can be a payment device, such as a mobile phone or a display device with payment functionality. When taking a ride, users can generate and display a payment code on their mobile phone, which can then be scanned by the QR code scanner on the public transportation equipment to obtain payment request information. Therefore, this application can be applied to both QR code payment scenarios and public transportation payment scenarios. Furthermore, it should be noted that the generation and scanning of the payment code do not require an internet connection in any of the above steps.

[0056] Step 104: The scanning device outputs an account confirmation signal based on the payment request information;

[0057] The payment request information includes the first user's account, and the scanning device pre-stores a list of users with outstanding payments and a blacklist. By comparing the first user's account with the list of users with outstanding payments and the blacklist, it can be determined whether the first user's account is on the list of users with outstanding payments or the blacklist. Finally, based on the determination result, an account confirmation signal is output.

[0058] It should be noted that the list of users with outstanding payments and the blacklist stored in the scanning device can be updated and stored when the scanning device is connected to the network, so that the terminal device can directly access them when it is offline. This ensures that the list is updated in real time and confirms the account information in the offline state.

[0059] The scanning device is equipped with signal lights. Therefore, the account confirmation signal can be output through the sequential display of the lights or through different colors displayed by the lights.

[0060] Step 105: The terminal device detects the account confirmation signal output by the scanning device and obtains the account status information;

[0061] The terminal device is equipped with a camera, which allows it to detect the light signals displayed by the scanning device and thus obtain account status information. Account status information includes normal status, overdue payment status, and blacklist status.

[0062] Step 106: If the account status information is normal, the terminal device generates a payment confirmation code based on the payment confirmation information.

[0063] Step 107: The terminal device displays a payment confirmation code so that the scanning device can scan it.

[0064] The payment confirmation code includes a second synchronization string, a second timestamp, and a second user account. The second synchronization string is generated based on the first synchronization string; specifically, a preset value can be added to the first synchronization string to obtain the second synchronization string. The second timestamp represents the real-time time in which the payment confirmation code was generated. The first user account can be used as the second user account to generate the payment confirmation code.

[0065] Step 108: The scanning device scans the payment confirmation code displayed on the terminal device to obtain payment confirmation information;

[0066] Step 109: If the payment request information and the payment confirmation information match, the scanning device generates an offline order so that the backend server can deduct the payment from the account bound to the terminal device based on the offline order.

[0067] A matching payment request and payment confirmation means that the following three conditions are met:

[0068] (1) The third synchronization string after the first synchronization string is accumulated with a preset value is the same as the second synchronization string;

[0069] (2) The difference between the second timestamp and the first timestamp is within a preset time period;

[0070] (3) The first user account is the same as the second user account.

[0071] If the payment request information matches the payment confirmation information, it means that the payment code and the payment confirmation code were generated by the same terminal device within a preset time period. This further indicates that both operations were performed by the same user using the same terminal device, which not only enables payment in offline mode but also improves the security of the payment process.

[0072] In one example Figure 2 The flowchart of an example in this embodiment is shown. Specifically, it is illustrated by taking the example of a user scanning the transit code on a terminal device while the user is offline.

[0073] Step 201: The scanning device first identifies the ride code (i.e., the payment request code and payment confirmation code in this application), decrypts the ride code with the ride code public key PUK, and obtains the user ID (i.e., the first user account and the second user account, and the synchronization string syn (i.e., the first synchronization string and the second synchronization string).

[0074] Step 202: The scanning device determines whether the user is in arrears or a blacklisted user (i.e., the account status information in this application) based on the user ID (i.e., the first user account).

[0075] Step 203: The scanning device compares the ID2=ID1 (i.e., the first user account is the same as the second user account) and the synchronization string syn2=syn+1 (i.e., the third synchronization string is the same as the second synchronization string) of the ride code user.

[0076] Step 204: The scanning device confirms whether ID2 is equal to D1 and whether syn2 is equal to syn+1.

[0077] Step 205: When ID2 = D1 and syn2 = syn+1, the scanning device will indicate that the code scan was successful.

[0078] Step 206: Based on the successful scanning of the code, send the corresponding signal light operation command (i.e., account confirmation signal);

[0079] Step 207: If the user is in arrears or is a blacklisted user, the system will prompt that the code scanning failed and send the corresponding signal light operation command.

[0080] Step 208: If the scanning device indicates that the scan was successful, an offline order is generated and sent to the backend system (i.e., the backend server) to deduct the payment from the user's bound account.

[0081] Step 209: If ID2 is not equal to ID1 or syn2 is not equal to syn+1, register and store the user ID and synchronization string syn, and re-execute step 203.

[0082] In another example, Figure 3 The flowchart of another example in this embodiment is shown. Specifically, it is used as an example to illustrate the generation of a ride code by the terminal device when the user is offline.

[0083] Step 301: Initialize the boarding page;

[0084] Step 302: Determine whether the terminal device has a ride code data cache;

[0085] Step 303: If the terminal device has a ride code data cache, obtain the terminal device's timestamp H (i.e., the first timestamp), concatenate it with the user ID (i.e., including the first user account) and the synchronization string syn (i.e., the first synchronization string) to obtain the ride code plaintext C;

[0086] Step 304: Encrypt the plaintext C of the ride code using the ride code private key PRK;

[0087] Step 305: Generate a QR code from the encrypted ride code and display it on the page (i.e., display the payment confirmation code and payment code);

[0088] Step 306: Upon receiving a signal light instruction (i.e., account confirmation signal), determine whether it is a confirmation instruction (i.e., normal status);

[0089] Step 307: If the traffic light command is a confirmation command, then sync string syn+1;

[0090] Execute step 303 to obtain the terminal device's timestamp H (i.e., the second timestamp), concatenate it with the user ID (i.e., including the second user account) and the synchronization string syn (i.e., syn+1, which is the second synchronization string) to obtain the ride code plaintext C;

[0091] Step 308: If the traffic light command is not a confirmation command, proceed to the overdue payment stage;

[0092] Step 309: If the terminal device does not have a ride code data cache, it requests user data from the backend server.

[0093] In this embodiment, by employing a two-stage verification process between the scanning device and the terminal device—based on the payment code and payment confirmation code—the scanning device can verify the terminal device's identity twice. By comparing the payment request and confirmation information during the two verification processes, it verifies whether the terminal device belongs to the same user, preventing unauthorized or duplicate transactions. This ensures the authenticity and uniqueness of the terminal device's payment information and avoids the security issues that arise with one-way verification by the scanning device. Furthermore, by recording offline orders between the terminal device and the scanning device, offline payments can be implemented, further enhancing the security of the payment code during offline payments.

[0094] In one specific embodiment of this application, the step of scanning the payment code displayed on the terminal device to obtain payment request information includes:

[0095] The scanning device scans the payment code displayed on the terminal device to obtain the first encrypted information, which is obtained by the terminal device through encrypting the payment request information with a private key;

[0096] The scanning device decrypts the first encrypted information based on the pre-acquired public key to obtain the first synchronization string, the first timestamp, and the first user account;

[0097] To ensure security during the payment process, after the terminal device generates the initial payment code, the private key of the transit code obtained by the terminal device can be used to encrypt the initial payment code, thereby obtaining the final payment code.

[0098] Correspondingly, the scanning device stores a public key, which is used to decrypt the payment code and obtain the first synchronization string, the first timestamp, and the first user account corresponding to the payment code.

[0099] In one embodiment of this application, the step of scanning the payment confirmation code displayed on the terminal device to obtain payment confirmation information includes:

[0100] The scanning device scans the payment confirmation code displayed on the terminal device to obtain the second encrypted information, which is obtained by the terminal device encrypting the payment confirmation information using the private key;

[0101] The scanning device decrypts the second encrypted information based on the public key to obtain the second synchronization string, the second timestamp, and the second user account.

[0102] The scanning device is equipped with a scanning system module, which mainly executes the steps described in the above embodiments. Specifically, to ensure security during the payment process, after the terminal device generates the initial payment confirmation code, the initial payment confirmation code can be encrypted using the private key of the transit code obtained by the terminal device, thereby obtaining the payment confirmation code.

[0103] Correspondingly, the scanning device stores a public key, which is used to decrypt the payment confirmation code, thereby obtaining the first synchronization string, the first timestamp, and the first user account corresponding to the payment confirmation code.

[0104] It should be noted that, to improve payment efficiency, the same public-private key pair can be used in the encryption and decryption processes of the payment code and payment confirmation code. However, to further enhance payment security, different public-private key pairs can be used in the encryption and decryption processes of the payment code and payment confirmation code. This application does not impose any restrictions on this.

[0105] In this embodiment, the payment code and payment confirmation code generated by the terminal device are decrypted by a scanning device to obtain payment request information and payment confirmation information, respectively, which can improve the security of the payment process.

[0106] In one embodiment of this application, the step of outputting an account confirmation signal based on payment request information includes:

[0107] Based on the first user account, the preset list of users in arrears, and the preset blacklist, determine the account status information of the terminal device;

[0108] If the account status information is normal, a QR code scanning signal will be displayed;

[0109] If the account status is in arrears, an arrears warning will be displayed;

[0110] If the account status information is blacklisted, a blacklist signal will be displayed.

[0111] In this embodiment, the list of users with outstanding payments and the blacklist can be updated by retrieving the latest list from the backend server when the scanning device is connected to the internet, so that it can be used when the scanning device is offline.

[0112] The scanning device is equipped with a signal light module, which is responsible for converting account status information into a flashing light signal through specific instruction encoding. The clock cycle of the signal light can be set to 0.12s, meaning that the time for one on and one off cycle is 0.24s. The relevant instruction encoding rules are as follows:

[0113] Table 1-1 Traffic Light Command Encoding Table

[0114] A0 111111 QR code recognition status Standby command A1 111000 Scan to confirm Work instructions A2 111001 QR code signal Work instructions A3 111010 Overdue payment signal Work instructions A4 111011 Blacklist signal Work instructions

[0115] The flashing of the light is controlled by binary data, where "1" controls the light to be on and "0" controls the light to be off. After receiving the coded instruction of account status information, the module will execute it in a loop. For example, if the "A1" instruction is received, the signal light will flash according to the code "111000111000111000".

[0116] The default signal for the indicator light is "111111", which means it is constantly lit and in the barcode scanning and recognition state. When the barcode scanning device recognizes a payment code or payment confirmation code, it will issue a working command; when it does not recognize a payment code or confirmation code, it will issue a standby command.

[0117] By using the above steps, the account status information is encoded in binary form to control the output of the signal light module, enabling signal transmission between the scanning device and the terminal device in offline mode, and ensuring information interaction between the two devices.

[0118] In one embodiment of this application, to ensure that the graphic codes in both scanning processes are generated by the same terminal device, an offline order is generated when the payment request information and payment confirmation information match, including:

[0119] Obtain the third synchronization string after adding a preset value to the first synchronization string, and the time difference between the second timestamp and the first timestamp;

[0120] If the first user account and the second user account are the same, the third synchronization string is the same as the second synchronization string, and the time difference is within a preset time period, an offline order is generated.

[0121] The aforementioned preset values ​​can be 1, 2, 3, etc., and this application does not impose any restrictions. In this embodiment, to ensure security during the payment process, verifying whether the first user account and the second user account are the same ensures that the user is using the same account for payment. Verifying whether the second timestamp and the first timestamp are within a preset time period ensures that the generation interval of the payment code and payment confirmation code is within the set time range when the user makes a payment. Verifying whether the third synchronization string is the same as the second synchronization string ensures that the user is using the same terminal device during the payment process.

[0122] If the payment request information and payment confirmation information match, the generated offline order can be temporarily stored in the scanning device. When the scanning device detects a network connection, it can send the offline order to the backend server, so that the backend server can deduct the payment from the user account bound to the terminal device and complete the payment.

[0123] In one embodiment of this application, the step of generating a payment code based on payment request information in the offline code-based payment method applied to a terminal device provided in this application embodiment further includes the following steps:

[0124] The payment request information is encrypted using a preset private key to obtain the first encrypted information;

[0125] Based on the first encrypted information, a payment code is generated;

[0126] A payment confirmation code is generated based on the payment confirmation information, including:

[0127] The payment confirmation information is encrypted using the private key to obtain the second encrypted information;

[0128] A payment confirmation code is generated based on the second encrypted information.

[0129] The first encrypted information includes an encrypted first timestamp, a first synchronization string, and a first user account. Concatenating the first timestamp, the first synchronization string, and the first user account yields an initial payment code, which is then encrypted using a private key to obtain the final payment code. The second encrypted information includes a second timestamp, a second synchronization string, and a second user account. Concatenating these information yields an initial payment confirmation code, which is then encrypted using a private key to obtain the final payment confirmation code. In this embodiment, encrypting the payment request information and payment confirmation information using a private key enhances the security of the payment process.

[0130] In one embodiment of this application, before the step of encrypting payment confirmation information with a private key to obtain second encrypted information, the method further includes:

[0131] Get the second timestamp and the second synchronization string after accumulating a preset value into the first synchronization string. The second timestamp is the current timestamp.

[0132] Payment confirmation information is obtained based on the first account information, the second synchronization string, and the second timestamp.

[0133] For example, if the first account information is ID1, the first synchronization string is 11, the first timestamp is 7 o'clock, and the preset value is 2, then the second account information is also ID1, the second synchronization string can be 13, and the second timestamp is the real-time time when the payment confirmation information is generated, which can be 7:01.

[0134] In this embodiment, by generating payment confirmation information based on payment request information, it can be ensured that the payment request information and payment confirmation information both originate from the same terminal device during the subsequent matching verification process.

[0135] In one embodiment of this application, the step of detecting the account confirmation signal output by the barcode scanning device and obtaining account status information includes:

[0136] Record multiple consecutive image frames, which are obtained by recording account confirmation signals;

[0137] Each image frame is binarized to obtain the image frames with the lights on and the image frames with the lights off.

[0138] The account status information is determined based on the arrangement order of the light-on image frames and the light-off image frames, as well as the preset arrangement judgment order. The arrangement judgment order is used to determine the account status information.

[0139] In this embodiment, a camera device is installed on the terminal device. The camera device is used to record video of the signal light on the barcode scanning device, and then extract multiple image frames from the video. The number of image frames can be 25.

[0140] Binarization is the process of setting the grayscale value of pixels in an image frame to 0 or 255, thus giving the entire image frame a distinct black and white effect. In this embodiment, the grayscale value of the lit areas in the image frame can be set to 255, while the grayscale value of the remaining areas can be set to 0. This results in each image frame being divided into lit image frames and unlit image frames.

[0141] After obtaining the lit and unlit image frames, the lit image frames can be marked as 1, and the unlit image frames can be marked as 0. By matching the order of the lit and unlit image frames within a preset clock cycle with the signal light instruction encoding table described in the above embodiment, the account status information corresponding to the account confirmation signal can be determined.

[0142] In one example, a 25fps video is recorded using the front-facing camera of the terminal device. Each frame of the video is then binarized so that the grayscale value of the illuminated area of ​​the traffic light is 255, and the grayscale value of the rest is 0. A clock cycle is defined as three frames. Within a clock cycle, if the grayscale value of the illuminated area of ​​the traffic light is 255 in two or more frames, a signal "1" is recorded; if the grayscale value of the illuminated area of ​​the traffic light is 0 in two or more frames, a signal "0" is recorded. When the signal recorded for four consecutive clock cycles is "1110", it indicates that a work instruction has been received. This signal, along with the signals from the next two clock cycles, forms a complete work instruction. By matching the traffic light instruction encoding table, the corresponding instruction is identified, and thus the account status information is obtained.

[0143] In another embodiment of this application, after determining the account status information based on the arrangement order of the lit image frames and the unlit image frames, and a preset arrangement judgment order, the method further includes:

[0144] If the account status information is normal, then stop recognition and generate a payment confirmation code;

[0145] If the account status information is in arrears, the payment certificate cache will be cleared and a reminder to pay the outstanding fees will be issued. The reminder will guide the customer to complete the payment of outstanding fees online. The payment certificate cache includes payment request information.

[0146] If the account status information is blacklisted, a blacklist notification will be issued. The blacklist notification is used to guide the customer to contact customer service to process the outstanding payment.

[0147] In this embodiment, if a user is in arrears and completes the payment, the backend server removes the user from the list of in arrears users and deducts points from the user's ride credit score X. It then returns a new ride certificate M (containing the user ID and payment account), the user's ride certificate public key PUK_C, and the private key PRK_Q used to generate the ride code, which are encrypted and stored on the terminal device.

[0148] The deduction rules for the above-mentioned ride credit score X are as follows:

[0149] X = X - 10n

[0150] Where n represents the number of times the user has accumulated overdue payments.

[0151] When a user's ride credit score X is less than 0, the customer will be added to the blacklist. If the user wants to be removed from the blacklist, they need to contact customer service for assistance.

[0152] In this embodiment, a payment credit value mechanism is used to regulate and constrain users' good payment behavior.

[0153] Figure 4 This illustration shows a flowchart of a payment method based on an offline code according to another embodiment of this application. In yet another embodiment of this application, before the step of generating a payment code based on payment request information, the payment method based on an offline code further includes:

[0154] Send a registration request to the backend server so that the backend server can generate the terminal device's first user account, the first user account status, and the initial credit value;

[0155] Receive the first user account, the status of the first user account, and the private key from the backend server;

[0156] If the first user account is in a normal state, execute: Generate a payment code based on the payment request information.

[0157] In this implementation, when a user has a mobile terminal device A and needs to use the payment function, if the user is a new user, it is necessary to ensure that the device network communication is normal, guide the user to register, perform identity verification and account binding. After successful registration and login, the backend server records a ride credit value X for the user, with an initial value of 100; and stores the ride ID, user status S, and private key assigned to the terminal device returned by the backend server.

[0158] Additionally, if the user is already logged in, they will be directed to the payment code display page (i.e., the ride code page) by default. If the user is on the blacklist, the locally stored payment code cache data will be cleared, and the user will be guided to complete the payment of outstanding fees. After the backend server removes the user from the blacklist, it will encrypt and store the returned new ride code data.

[0159] In this embodiment, the terminal device registers its account by sending a registration request to the backend server, which provides a verification basis for the verification and payment between the terminal device and the scanning device, and improves the security of offline payment.

[0160] Figure 5 A schematic diagram of the structure of a payment device based on an offline code according to an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0161] Reference Figure 5 The offline code-based payment device 500 may include:

[0162] The first scanning module 501 is used to scan the payment code displayed on the terminal device to obtain payment request information, the payment request information including a first synchronization string, a first timestamp and a first user account;

[0163] The signal light module 502 is used to output an account confirmation signal based on the payment request information;

[0164] The second scanning module 503 is used to scan the payment confirmation code displayed on the terminal device to obtain payment confirmation information. The payment confirmation code is generated by the terminal device based on the account confirmation signal. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account.

[0165] The matching module 504 is used to generate an offline order when the payment request information and the payment confirmation information match, so that the backend server deducts the payment from the account bound to the terminal device based on the offline order.

[0166] Optionally, the first scanning module 501 includes:

[0167] The first scanning submodule is used to scan the payment code displayed on the terminal device to obtain the first encrypted information, which is obtained by the terminal device through encrypting the payment request information with a private key.

[0168] The first decryption submodule is used to decrypt the first encrypted information based on the pre-acquired public key to obtain the first synchronization string, the first timestamp, and the first user account;

[0169] Optionally, the second scanning module includes:

[0170] The second scanning submodule is used to scan the payment confirmation code displayed on the terminal device to obtain the second encrypted information. The second encrypted information is obtained by the terminal device encrypting the payment confirmation information using the private key.

[0171] The second decryption submodule is used to decrypt the second encrypted information based on the public key to obtain the second synchronization string, the second timestamp, and the second user account.

[0172] Optionally, the traffic light module 502 includes:

[0173] The first determining submodule is used to determine the account status information of the terminal device based on the first user account, a preset list of users in arrears, and a preset blacklist.

[0174] The first display submodule is used to display the scanning signal when the account status information is in a normal state;

[0175] The second display submodule is used to display the overdue payment signal when the account status information is in an overdue payment state;

[0176] The third display submodule is used to display the blacklist signal when the account status information is in a blacklist state.

[0177] Optionally, the matching module 504 includes:

[0178] The first acquisition submodule is used to acquire the third synchronization string after the first synchronization string is accumulated with a preset value, and the time difference between the second timestamp and the first timestamp;

[0179] The order submodule is used to generate offline orders when the first user account is the same as the second user account, the third synchronization string is the same as the second synchronization string, and the time difference is within a preset time period.

[0180] The offline code-based payment device 500 provided in this application embodiment can implement the various processes implemented in the aforementioned method embodiments, and will not be repeated here to avoid repetition.

[0181] Figure 6 A schematic diagram of the structure of a payment device based on an offline code according to an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0182] Reference Figure 6 Optionally, the offline code-based payment device 600 further includes:

[0183] The first generation module 601 is used to generate a payment code based on payment request information, wherein the payment request information includes a first synchronization string, a first timestamp, and a first user account.

[0184] The first display module 602 is used to display the payment code so that the scanning device can scan it;

[0185] The detection module 603 is used to detect the account confirmation signal output by the barcode scanning device and obtain account status information;

[0186] The second generation module 604 is used to generate a payment confirmation code based on payment confirmation information when the account status information is in a normal state. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account.

[0187] The second display module 605 is used to display the payment confirmation code so that the scanning device can scan it.

[0188] Optionally, the first generation module 601 includes:

[0189] The first acquisition submodule is used to encrypt the payment request information using a preset private key to obtain the first encrypted information;

[0190] The first generation submodule is used to generate a payment code based on the first encrypted information;

[0191] Optionally, the second generation module 604 includes:

[0192] The second acquisition submodule is used to encrypt the payment confirmation information using the private key to obtain the second encrypted information;

[0193] The second generation submodule is used to generate a payment confirmation code based on the second encrypted information.

[0194] Optionally, the offline code-based payment device 600 further includes:

[0195] The first acquisition module is used to acquire the second timestamp and the second synchronization string after the first synchronization string is accumulated with a preset value, wherein the second timestamp is the current timestamp;

[0196] The second acquisition module is used to obtain the payment confirmation information based on the first account information, the second synchronization string, and the second timestamp.

[0197] Optionally, the detection module 603 includes:

[0198] The recording submodule is used to record multiple consecutive image frames, which are obtained by recording the account confirmation signal;

[0199] The processing submodule is used to perform binarization processing on each of the image frames to obtain the light-on image frame and the light-off image frame.

[0200] The second determining submodule is used to determine the account status information based on the arrangement order of the lit image frames and the turned-off image frames, as well as a preset arrangement judgment order, wherein the arrangement judgment order is used to determine the account status information.

[0201] The offline code-based payment device 600 provided in this application embodiment can implement the various processes implemented in the aforementioned method embodiments, and will not be repeated here to avoid repetition.

[0202] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

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

[0205] When processor 701 executes the program, it implements the steps in any of the above method embodiments.

[0206] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 702 and executed by processor 701 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

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

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

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

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

[0211] In one example, the electronic device may also include a communication interface 703 and a bus 710. The processor 701, memory 702, and communication interface 703 are connected via the bus 710 and communicate with each other.

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

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

[0214] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores program instructions; when these program instructions are executed by a processor, they implement any of the methods in the above embodiments.

[0215] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0216] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0217] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0218] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0219] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

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

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

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

Claims

1. A payment method based on offline codes, applied to a QR code scanning device, characterized in that, The method includes: Scan the payment code displayed on the terminal device to obtain payment request information, which includes a first synchronization string, a first timestamp, and a first user account; Based on the payment request information, an account confirmation signal is output. The account confirmation signal includes a QR code scanning signal, an overdue payment signal, and a blacklist signal. The QR code scanning device is equipped with a signal light. The account confirmation signal is output through the sequential display of the lights by the signal light, or through the different colors displayed by the signal light. Scan the payment confirmation code displayed on the terminal device to obtain payment confirmation information. The payment confirmation code is generated by the terminal device based on the account confirmation signal. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account. If the payment request information and the payment confirmation information match, an offline order is generated so that the backend server can deduct the payment from the account bound to the terminal device based on the offline order; If the payment request information and the payment confirmation information match, an offline order is generated, including: Obtain the third synchronization string after the first synchronization string is accumulated with a preset value, and the time difference between the second timestamp and the first timestamp; An offline order is generated when the first user account is the same as the second user account, the third synchronization string is the same as the second synchronization string, and the time difference is within a preset time period.

2. The payment method based on offline codes as described in claim 1, characterized in that, The step of obtaining payment request information from the payment code displayed on the scanning terminal device includes: Scan the payment code displayed on the terminal device to obtain the first encrypted information, which is obtained by the terminal device encrypting the payment request information with a private key; Based on the pre-acquired public key, the first encrypted information is decrypted to obtain the first synchronization string, the first timestamp, and the first user account; The step of obtaining payment confirmation information by scanning the payment confirmation code displayed on the terminal device includes: Scan the payment confirmation code displayed on the terminal device to obtain the second encrypted information, which is obtained by the terminal device encrypting the payment confirmation information using the private key; Based on the public key, the second encrypted information is decrypted to obtain the second synchronization string, the second timestamp, and the second user account.

3. The payment method based on offline codes as described in claim 1, characterized in that, The step of outputting an account confirmation signal based on the payment request information includes: Based on the first user account, the preset list of users with outstanding fees, and the preset blacklist, the account status information of the terminal device is determined; When the account status information is normal, the scanning signal is displayed; If the account status information indicates an outstanding payment, the outstanding payment signal will be displayed. If the account status information is in a blacklist state, the blacklist signal will be displayed.

4. A payment method based on offline codes, applied to terminal devices, characterized in that, The method includes: A payment code is generated based on payment request information, which includes a first synchronization string, a first timestamp, and a first user account. Display the payment code to allow the scanning device to scan it; The terminal device detects the account confirmation signal output by the scanning device to obtain account status information. The terminal device is equipped with a camera device, which detects the light signal displayed by the scanning device to obtain the account status information. The account status information includes normal status, overdue status, and blacklist status. If the account status information is normal, a payment confirmation code is generated based on the payment confirmation information, which includes a second synchronization string, a second timestamp, and a second user account. Display the payment confirmation code to enable the scanning device to scan it; Before generating the payment confirmation code based on the payment confirmation information, the method further includes: Obtain the second timestamp and the second synchronization string after accumulating a preset value into the first synchronization string, where the second timestamp is the current timestamp; The payment confirmation information is obtained based on the second user account, the second synchronization string, and the second timestamp, wherein the first user account is the same as the second user account.

5. The payment method based on offline codes as described in claim 4, characterized in that, The step of generating a payment code based on payment request information includes: The payment request information is encrypted using a preset private key to obtain the first encrypted information; Based on the first encrypted information, a payment code is generated; A payment confirmation code is generated based on the payment confirmation information, including: The payment confirmation information is encrypted using the private key to obtain the second encrypted information; A payment confirmation code is generated based on the second encrypted information.

6. The payment method based on offline codes as described in claim 4, characterized in that, The step of obtaining account status information by detecting the account confirmation signal output by the barcode scanning device includes: Record multiple consecutive image frames, which are obtained by recording the account confirmation signal; Each of the image frames is binarized to obtain the image frames with the lights on and the image frames with the lights off. The account status information is determined based on the arrangement order of the lit-up image frames and the lit-down image frames, as well as a preset arrangement judgment order. The arrangement judgment order is used to determine the account status information.

7. A payment device based on an offline code, characterized in that, The device includes: The first scanning module is used to scan the payment code displayed on the terminal device to obtain payment request information, which includes a first synchronization string, a first timestamp, and a first user account. The signal light module is used to output an account confirmation signal based on the payment request information. The account confirmation signal includes a QR code scanning signal, an overdue payment signal, and a blacklist signal. The QR code scanning device is equipped with a signal light. The account confirmation signal is output through the sequential display of the lights by the signal light, or through the different colors displayed by the signal light. The second scanning module is used to scan the payment confirmation code displayed on the terminal device to obtain payment confirmation information. The payment confirmation code is generated by the terminal device based on the account confirmation signal. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account. The matching module is used to generate an offline order when the payment request information and the payment confirmation information match, so that the backend server deducts the payment from the account bound to the terminal device based on the offline order; The matching module includes: The first acquisition submodule is used to acquire the third synchronization string after the first synchronization string is accumulated with a preset value, and the time difference between the second timestamp and the first timestamp; The order submodule is used to generate offline orders when the first user account is the same as the second user account, the third synchronization string is the same as the second synchronization string, and the time difference is within a preset time period.

8. A payment device based on an offline code, characterized in that, The device includes: The first generation module is used to generate a payment code based on payment request information, wherein the payment request information includes a first synchronization string, a first timestamp, and a first user account. The first display module is used to display the payment code for scanning by a scanning device; The detection module is used to detect the account confirmation signal output by the scanning device and obtain the account status information. The terminal device is equipped with a camera device, which detects the light signal displayed by the scanning device through the camera device to obtain the account status information, which includes normal status, overdue status and blacklist status. The second generation module is used to generate a payment confirmation code based on the payment confirmation information when the account status information is in a normal state. The payment confirmation information includes a second synchronization string, a second timestamp, and a second user account. The second display module is used to display the payment confirmation code so that the scanning device can scan it; The device further includes: The first acquisition module is used to acquire a second timestamp and a second synchronization string after the first synchronization string is accumulated with a preset value before the payment confirmation code is generated based on the payment confirmation information. The second timestamp is the current timestamp. The second acquisition module is used to obtain the payment confirmation information based on the second user account, the second synchronization string, and the second timestamp, wherein the first user account is the same as the second user account.

9. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the offline code-based payment method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the offline code-based payment method as described in any one of claims 1-6.

11. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the offline code-based payment method as described in any one of claims 1-6.

Images