Payment processing method and apparatus, electronic device, and server

Abstract

This application discloses a payment processing method and apparatus, an electronic device, and a server. The method includes: acquiring a personal identification code and payment data, wherein the personal identification code has M characters, and the payment data represents data generated when making a payment for a target business type, where M is an integer greater than 1; determining a salt value with N characters based on the personal identification code and payment data, where N is an integer multiple of M; determining signature information based on the salt value and payment data; and sending an authentication request message to the server, the authentication request message being used to request the server to authenticate the signature information to determine the security of the payment processing for the target business type. It is evident that by utilizing the personal identification code to generate a random salt value for each user and each payment data item, the electronic device or server only needs to maintain the personal identification code, thereby improving the flexibility of payment processing, preventing the salt value from being exposed or cracked, and enhancing the security of payment processing.

Description

Technical Field

[0001] This application relates to the field of payments, specifically to a payment processing method and apparatus, electronic device, and server. Background Technology

[0002] Mobile payment effectively combines mobile internet, electronic devices, and financial institutions to form a new type of payment system in the mobile internet era. Centered on electronic devices (such as mobile phones), it allows users to settle and pay for a range of selected services (such as digital products, goods, phone bills, gas and water bills, game top-ups, food delivery, tolls, etc.) anytime and anywhere without using cash, bank cards, or checks.

[0003] Currently, when a user makes a mobile payment for a selected service type, the electronic device generates certain payment data (payment messages, etc.) for the transaction, such as user information, order amount, business account information, and identification information of the selected service type. This payment data needs to undergo appropriate authentication processing to ensure the security of the transaction. However, further research is needed to improve the security of payment processing. Summary of the Invention

[0004] This application provides a payment processing method and apparatus, electronic device, and server, which aim to generate random salt values ​​for each user and each payment data by utilizing personal identification codes. This allows the electronic device or server to maintain only the personal identification codes, thereby improving the flexibility of payment processing, preventing the salt values ​​from being exposed or cracked, and enhancing the security of payment processing.

[0005] Firstly, a payment processing method according to this application includes:

[0006] Obtain a personal identification code and payment data. The personal identification code has M characters, and the payment data is used to represent the data generated when making a payment for the target business type, where M is an integer greater than 1.

[0007] A salt value with N characters is determined based on the personal identification code and the payment data, where N is an integer multiple of M;

[0008] The signature information is determined based on the salt value and the payment data;

[0009] Send an authentication request message to the server, the authentication request message being used to request the server to authenticate the signature information to determine the security of payment processing for the target business type.

[0010] Secondly, this application provides a payment processing method, including:

[0011] Obtain an authentication request message from an electronic device, the authentication request message being used to request authentication of the signature information in the authentication request message to determine the security of payment processing for the target business type;

[0012] The personal identification code is determined based on the authentication request message. The personal identification code has M characters, where M is an integer greater than 1.

[0013] A salt value with N characters is determined based on the personal identification code and the payment data in the authentication request message. The payment data is used to represent the data generated when making a payment for the target business type, and N is an integer multiple of M.

[0014] The target signature information is determined based on the salt value and the payment data;

[0015] The consistency between the signature information and the target signature information is compared to obtain a comparison result, which is used to determine the security of payment processing for the target business type.

[0016] The comparison result is sent to the electronic device.

[0017] Thirdly, a payment processing apparatus according to this application includes:

[0018] The acquisition unit is used to acquire a personal identification code and payment data. The personal identification code has M characters, and the payment data is used to represent the data generated when making a payment for a target business type, where M is an integer greater than 1.

[0019] The determining unit is configured to determine a salt value with N characters based on the personal identification code and the payment data, where N is an integer multiple of M;

[0020] The determining unit is further configured to determine signature information based on the salt value and the payment data;

[0021] The sending unit is used to send an authentication request message to the server, the authentication request message being used to request the server to authenticate the signature information to determine the security of the payment processing for the target business type.

[0022] Fourthly, a payment processing apparatus according to this application includes:

[0023] The acquisition unit is used to acquire an authentication request message from an electronic device, wherein the authentication request message is used to request authentication of the signature information in the authentication request message to determine the security of payment processing for the target business type.

[0024] The determining unit is configured to determine a personal identification code based on the authentication request message, wherein the personal identification code has M characters, where M is an integer greater than 1;

[0025] The determining unit is further configured to determine a salt value with N characters based on the personal identification code and the payment data in the authentication request message, wherein the payment data is used to represent the data generated when making payment for the target business type, and N is an integer multiple of M;

[0026] The determining unit is further configured to determine target signature information based on the salt value and the payment data;

[0027] A comparison unit is used to compare the consistency between the signature information and the target signature information to obtain a comparison result, which is used to determine the security of payment processing for the target business type.

[0028] A sending unit is used to send the comparison result to the electronic device.

[0029] Fifthly, an electronic device according to this application includes a processor, a memory, and a computer program or instructions stored in the memory, wherein the processor executes the computer program or instructions to implement the steps of the method designed in the first aspect above.

[0030] Sixthly, a server according to this application includes a processor, a memory, and a computer program or instructions stored in the memory, wherein the processor executes the computer program or instructions to implement the steps of the method designed in the second aspect above.

[0031] A seventh aspect is a computer-readable storage medium of this application, wherein it stores a computer program or instructions that, when executed, implement the steps in the method designed in the first or second aspect described above.

[0032] The eighth aspect is a computer program product of this application, comprising a computer program or instructions, wherein when the computer program or instructions are executed, they implement the steps in the method designed in the first or second aspect described above.

[0033] As can be seen, the embodiments of this application introduce a new payment processing flow, namely payment processing based on personal identification codes. By using personal identification codes to generate random salt values ​​for each user and each payment data, different salt values ​​are used for different users and different salt values ​​are used for each payment data, thereby improving the flexibility of payment processing.

[0034] In addition, by using personal identification codes to generate random salt values, electronic devices or servers only need to maintain personal identification codes, instead of storing a large number of salt values. This helps to prevent the salt values ​​from being exposed or cracked, and in turn, it helps to build more secure authentication processes and richer payment protection logic for various business types, thereby improving the security of payment processing. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0036] Figure 1 This is a schematic diagram of the architecture of a payment processing system according to an embodiment of this application;

[0037] Figure 2 This is a schematic diagram of the hardware and software system architecture of an electronic device according to an embodiment of this application;

[0038] Figure 3 This is a flowchart illustrating a payment processing method according to an embodiment of this application;

[0039] Figure 4 This is a flowchart illustrating another payment processing method according to an embodiment of this application;

[0040] Figure 5 This is a functional unit block diagram of a payment processing device according to an embodiment of this application;

[0041] Figure 6 This is a functional unit block diagram of another payment processing device according to an embodiment of this application;

[0042] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application;

[0043] Figure 8 This is a schematic diagram of the structure of a server according to an embodiment of this application. Detailed Implementation

[0044] To help those skilled in the art better understand the technical solutions of this application, the technical solutions in the embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art without creative effort regarding the embodiments of this application are within the scope of protection claimed in this application.

[0045] It should be understood that the terms "first," "second," etc., used in the embodiments of this application are used to distinguish different objects, rather than to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, software, product, or device that includes a series of steps or units is not limited to the listed steps or units, but also includes steps or units not listed, or other steps or units inherent to these processes, methods, products, or devices.

[0046] The term "embodiment" as used in the embodiments of this application means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0047] In the embodiments of this application, "at least one" refers to one or more, and "multiple" refers to two or more.

[0048] In this application's embodiments, "and / or" describes the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the following three cases: A exists alone, A and B exist simultaneously, and B exists alone. Here, A and B can be singular or plural. The character " / " can indicate that the preceding and following related objects are in an "or" relationship. Additionally, the symbol " / " can also represent a division sign, i.e., performing a division operation.

[0049] In the embodiments of this application, "at least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent the following seven cases: a, b, c, a and b, a and c, b and c, a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0050] In this application's embodiments, "authentication" can be interpreted as the same concept as "verification," "checking," or "inspection," and no specific restrictions are imposed on it.

[0051] Currently, when a user makes a mobile payment for a selected service type (such as digital products, goods, phone bills, gas and water bills, game top-ups, food delivery orders, tolls, etc.), the electronic device generates certain payment data (payment messages, etc.) for this transaction, such as user information, order amount, business account information, and identification information of the selected service type. This payment data needs to undergo corresponding authentication processing to ensure the security of the transaction. To improve the security of payment processing, this application embodiment considers performing corresponding authentication processing on the payment data.

[0052] The technical solutions and related concepts involved in the embodiments of this application will be described in detail below.

[0053] 1. Payment processing systems, electronic devices, and servers

[0054] In this embodiment, the user's mobile payment needs to be implemented through an electronic device. The electronic device can generate specific payment data based on the type of service the user needs to pay for, in order to complete the transaction. Simultaneously, the server can perform appropriate authentication processing on this payment data and feed back the authentication results to the electronic device, thereby completing the transaction and ensuring the security of the payment process.

[0055] 1) Payment processing system

[0056] To achieve the above processing, this application provides a payment processing system, which can be a payment management platform with a B / S architecture or a payment management platform with a C / S architecture, without any specific limitation.

[0057] For example, such as Figure 1 As shown, the payment processing system 10 includes an electronic device 110 and a server 120. The electronic device 110 and the server 120 can communicate with each other via a wireless network or wired data connection.

[0058] It should be noted that the wireless network may include mobile cellular networks (such as fourth-generation 4G or fifth-generation 5G mobile communication networks), satellite communication networks, Internet of Things (IoT), vehicle-to-everything (V2X) networks, wireless local area networks (WLANs), wide area networks (WANs), Bluetooth (BT), wireless fidelity (Wi-Fi), Zigbee, near field communication (NFC), ultra-wideband (UWB), light fidelity (LiFi), infrared (IR), etc.

[0059] The wired network can be constructed using data lines such as serial transmission interface data lines, asynchronous transmission interface (such as RS-232) data lines, universal serial bus (USB) data lines, metal wires, optical fibers, cables, and optical fiber cables.

[0060] In addition, the payment processing system 10 may also include other numbers of electronic devices and other numbers of servers, without specific limitations.

[0061] The electronic devices and servers described in the embodiments of this application will be described in detail below.

[0062] 2) Electronic devices

[0063] The electronic devices in the embodiments of this application may be handheld devices, vehicle-mounted devices, wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, projection devices, projectors, or other devices connected to a wireless modem. They may also be various specific forms of user equipment (UE), terminal devices, terminals, mobile terminals, mobile phones, smart screens, smart TVs, smartwatches, laptops, smart speakers, cameras, game controllers, microphones, stations (STA), access points (AP), mobile stations (MS), personal digital assistants (PDAs), personal computers (PCs), or relay devices, etc.

[0064] For example, electronic devices can be wearable devices. These wearable devices, also known as smart wearable devices, are a general term for intelligent devices that utilize wearable technology to intelligently design and develop everyday wearables, such as smart glasses, smart gloves, smartwatches, various smart bracelets with specific feature monitoring, and smart jewelry. These wearable devices can be worn directly on the body or integrated into the user's clothing or accessories; they are portable devices. These wearable devices can not only utilize dedicated hardware architectures but also dedicated software architectures for data interaction, cloud interaction, and more. These wearable smart devices can achieve complete or partial functionality without relying on other smart devices.

[0065] 3) Hardware and software systems of electronic devices

[0066] In the embodiments of this application, the software system of the electronic device may adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture or cloud architecture.

[0067] The hardware and software system of an electronic device may include a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer.

[0068] This hardware layer may include hardware such as CPU, memory management unit (MMU), and memory (also known as storage).

[0069] This memory can be used to store software programs and / or modules, and may include a program storage area and a data storage area.

[0070] This stored program area can be used to store the operating system or software programs required for at least one function. The operating system can be any one or more computer operating systems that implement business processing through processes. Examples include Android, RTOS (real-time operating system), UNIX, Linux, DOS, Windows, and Mac operating systems.

[0071] This storage area can be used to store data required or generated by the operating system or at least one function.

[0072] The following example uses a layered operating system to illustrate the hardware and software systems of electronic devices.

[0073] For example, such as Figure 2 As shown, Figure 2This is a schematic diagram of the hardware and software system architecture of an electronic device according to an embodiment of this application. The memory 220 stores an operating system layer 230. The operating system layer includes a kernel layer 2301, a system runtime library layer 2302, an application framework layer 2303, and an application layer 2304. The layers communicate with each other through software interfaces, and the kernel layer 2301, system runtime library layer 2302, and application framework layer 2303 belong to the operating system space. The processor 210 can execute computer programs or instructions stored in the memory 220 to perform related operations.

[0074] The processor 210 can be viewed as a complete system-on-chip (SOC) that can be used to run or load an operating system and may include one or more processing units.

[0075] For example, processor 210 may include at least one of the following: central processing unit (CPU), application processor (AP), microcontroller unit (MCU), single-chip microcomputer (SCM), microcontroller, graphics processing unit (GPU), image signal processor (ISP), controller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), baseband processor, neural-network processing unit (NPU), etc. Different processing units may be separate or integrated together. Additionally, processor 210 may also include memory 220.

[0076] The processor 210 may also include one or more communication interfaces. These communication interfaces may include at least one of the following: a serial peripheral interface (SPI), an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and a universal serial bus (USB) interface.

[0077] The memory 220 can be used to store computer programs or instructions, to store data, and to store the operating system layer 230. The processor 210 can call programs stored in the memory 220 to run the operating system. The memory 220 can save or cache instructions recently used or repeatedly used by the processor 210, and can also save or cache data, synchronizing or transmitting this data to other processors for execution.

[0078] The memory 220 may include at least one of random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0079] Kernel layer 2301 provides low-level operating system drivers for various hardware components of electronic devices, such as display drivers, audio drivers, camera drivers, Bluetooth drivers, Wi-Fi drivers, power management, NFC drivers, UWB drivers, mobile payment drivers, etc.

[0080] The system runtime library layer 2302 can be used to provide key feature support for the operating system through various C / C++ libraries. For example, the SQLite library provides database support, the OpenGL / ES library provides 3D graphics support, and the Webkit library provides browser engine support.

[0081] The system runtime layer 2302 can also be used to provide operating system runtime libraries, which mainly provide some core libraries that allow developers to write applications using scripting languages.

[0082] Application framework layer 2303 can be used to provide various application programming interfaces (APIs) and programming frameworks that may be used to build applications in application layer 2304, so that developers can use these APIs to create applications.

[0083] The application framework layer 2303 may include a window manager, content providers, a view system, a telephone manager, a resource manager, a notification manager, a message manager, an activity manager, a package manager, a location manager, a payment manager, etc.

[0084] Application layer 2304 belongs to user space, and at least one application (or simply "application") runs in application layer 2304. These applications can be native applications that come with the operating system or third-party applications developed by third-party developers. For example, the application layer can include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, SMS, and mobile payment.

[0085] 4) Server

[0086] The server in this application embodiment can be a software or hardware unit used to provide functions such as payment authentication processing.

[0087] For example, the hardware and software unit can be Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) platform, database, etc.

[0088] In addition, the server can be a cloud server, hardware server, software server, hardware and software server, authentication server, payment authentication / verification management platform, IoT server, web server, application server, load balancer (Nginx), data center network equipment, personal computer (PC), computing device, network equipment in 5G system, and network equipment in future evolved public land mobile network (PLMN), computer supporting 802.11 protocol, etc., without specific restrictions.

[0089] 2. Payment Processing Flow

[0090] Currently, the Unified Payment Interface (UPI) is a dominant payment method in the mobile payment field. UPI is increasingly popular in India, holding over 50% market share. Consequently, numerous mobile wallet platforms and payment apps exist for UPI payments, such as Paytm, Google Pay, MiPay, and PhonePE. Users can select the service type within these platforms or apps to perform mobile payment transactions.

[0091] When a user makes a mobile payment for a selected service type, the electronic device controls the mobile wallet platform or payment application to generate payment data during the payment process. Simultaneously, the electronic device stores a fixed number (letters, combinations of numbers and letters, etc.) as a salt value locally. The electronic device then mixes the payment data with this fixed salt value to generate a signature, which is then authenticated by the server. Finally, upon successful authentication, the mobile payment for the selected service type is completed.

[0092] However, in the aforementioned payment process, when an electronic device is decompiled, the fixed salt value stored in the device can be easily discovered (exposed) or cracked, making the generated signature information easy to forge and tamper with, which may bring risks and insecurity to mobile payments.

[0093] In addition, using a fixed salt value may result in the same payment data (payment message) generating the same signature information on different electronic devices, which may also bring risks and insecurity to mobile payments.

[0094] Based on this, this application introduces a new payment processing flow, which uses a Personal Identification Number (PIN) to generate a random salt value for each user and each payment data. This ensures that different users use different salt values, and each payment data also uses a different salt value, thereby improving the flexibility of payment processing. At the same time, using the PIN to generate random salt values ​​also allows electronic devices or servers to only maintain the PIN, without having to store a large number of salt values. This helps to prevent the salt values ​​from being exposed or cracked, and thus facilitates the construction of more secure authentication processing and richer payment protection logic for various business types, thereby improving the security of payment processing.

[0095] The following is a detailed explanation of the relevant concepts involved in the new payment processing flow of this application embodiment, as well as the beneficial effects that can be achieved.

[0096] 1) Business Type

[0097] In this embodiment, the business type can be used to represent a business that can be subject to payment (mobile payment / transaction) behavior, such as digital products, goods, phone bills, gas and water bills, game top-ups, food delivery orders, toll fees, etc. The identification information of the business type can be used to uniquely identify the business type, so that the business identifier can be identified and distinguished through the identification information of the business type.

[0098] The service type can be provided by the mobile wallet platform or payment application (APP) of the electronic device. Therefore, users can select the service type in the mobile wallet or payment application to perform relevant mobile payment activities according to their own needs.

[0099] It's important to note that an application, also known as an app, is a program designed to perform one or more specific tasks or functions. These programs run on the operating system, interact with the user at the application layer, and have a visual user interface. For example, an application can run on... Figure 2 The application layer 2304 is shown.

[0100] Payment applications can refer to applications that have payment (mobile payment / transaction, etc.) functions.

[0101] 2) Payment data

[0102] In this embodiment, payment data, also known as payment messages, can be used to represent data generated when making payments for a business type (mobile payment / transaction, etc.), such as user information, order amount, business account information, and identification information of the selected business type. The business account information may include UPI account, bank card account, user account on a mobile wallet platform or payment application, etc.

[0103] It is understandable that when a user selects a service type on a mobile wallet platform or payment application to perform a related mobile payment action, the electronic device can control the mobile wallet platform or payment application to generate payment data.

[0104] In addition, payment data can be Hypertext Transfer Protocol (HTTP) data.

[0105] 3) User identification information (User ID)

[0106] In this embodiment of the application, user identification information can be used to uniquely identify a user so that the user can be identified and distinguished.

[0107] It should be noted that when users register / login to mobile wallet platforms or payment applications, they provide relevant personal information, such as their registration / login account password and contact information. Therefore, mobile wallet platforms or payment applications can use this personal information as user identification information.

[0108] 4) Personal Identification Number (PIN)

[0109] In this embodiment of the application, the PIN code may be generated based on user identification information and function addresses in the operating system's dynamic library files.

[0110] It should be noted that during the entire payment process, a dynamic library file exists in the operating system of the electronic device. This dynamic library file can be a dynamic library developed in C / C++ on the operating system, used to implement the underlying payment (mobile payment / transaction, etc.) behavior logic, such as the SO file in Android / Linux.

[0111] Meanwhile, throughout the entire payment processing flow, this dynamic library file can maintain multiple functions (such as payment functions or Virtual Payment Account (VPA) functions) to implement the underlying (mobile payment / transaction, etc.) behavioral logic.

[0112] The process of a user selecting a service type on a mobile wallet platform or payment application to perform related payment (mobile payment / transaction, etc.) can be understood as the dynamic library file being loaded and the functions in the dynamic library file being called.

[0113] At this point, the electronic device (kernel or processor) extracts the user identification information and the function address in the dynamic library file (the function address can be used to represent the scheduled function), and generates a PIN code using a certain algorithm based on the user identification information and the function address in the dynamic library file.

[0114] As can be seen, since the PIN code is generated based on the user identification information and the function address on the dynamic library file, the PIN code is not directly transmitted between the electronic device and the server. Only the user identification information is transmitted. Therefore, it helps to avoid the PIN code being exposed and discovered, and ensures the security of payment processing.

[0115] Furthermore, different users (i.e., different user identification information) and different versions of dynamic library files will generate different PIN codes. Therefore, the PIN code in this application embodiment can be used to uniquely identify users and / or dynamic library files.

[0116] In some possible designs, the PIN code in this application embodiment may have M characters (M is an integer greater than 1). Here, a character can also be understood as a byte, and there is no specific limitation on this.

[0117] For example, a PIN code with 16 characters is “12345678ABCDEFGH”.

[0118] It should be noted that the embodiments of this application can use the ASCII table to convert the characters in the PIN code into binary, decimal or hexadecimal, etc., for easier processing.

[0119] For example, the character "A" can be converted to binary as "01000001", decimal as "65", or hexadecimal as "41" using the ASCII table.

[0120] 5) PIN code conversion processing

[0121] This application embodiment can convert a PIN code into an m*n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1. When n is 1, the m*n matrix can be an m-order vector.

[0122] It should be noted that an m*n matrix can also be understood as a table (table) with m rows and n columns, and there are no specific restrictions on it.

[0123] In some possible designs, when m is an integer greater than 1 and less than M, and n is an integer greater than 1, the M characters in the PIN code are arranged sequentially in either row-first-column or column-first-row order to generate an m*n matrix.

[0124] For example, with M = 16, m = 4, and n = 4, if the PIN code is "ABCDEFGH12345678", then the 16 characters of the PIN code will be arranged sequentially row-wise to generate the following 4*4 matrix:

[0125]

[0126] For example, with M=16, m=2, and n=8, if the PIN code is "ABCDEFGH12345678", then the 16 characters of the PIN code are arranged sequentially column-wise and row-wise to generate the following 2*8 matrix:

[0127]

[0128] In some possible designs, when m is M and n is 1, the M characters in the PIN code are arranged sequentially according to their order of appearance to generate an M-order vector.

[0129] In summary, the purpose of converting the PIN code into an m*n matrix is ​​as follows: Since an m*n matrix can have m rows and n columns, in the subsequent salt value generation process, the characters corresponding to the remainders in the m*n matrix can be extracted as salt value masks using either a row-first, column-later or column-first, row-later order. That is, the m*n matrix is ​​used as a salt value mask, thereby generating different salt values ​​through different orders, which helps to improve the flexibility of payment processing (authentication processing, etc.).

[0130] 6) Salt value generation algorithm

[0131] It should be noted that in cryptography, salt, also known as "salting," refers to the process of inserting / adding specific (extra) strings at arbitrary fixed positions in the original sequence to be hashed, thereby shuffling the order of the original sequence and causing the generated hash result to differ from the original sequence's hash result. This makes the generated hash result more difficult to crack or easy to obtain the original sequence, thus greatly reducing the risk of password leakage due to stolen user data.

[0132] The embodiments of this application can generate salt values ​​using the following salt value generation algorithm:

[0133] • The payment data is processed using a hash (SHA) algorithm to generate a target character sequence of N characters, where N is an integer multiple of M.

[0134] It's important to note that SHA stands for Secure Hash Algorithm, and SHA-1 and SHA-2 are two different versions of this algorithm. SHA-1 and SHA-2 differ in their construction (how the hash result is created from the original data) and the bit length of the signature. SHA-1 is a 160-bit hash, meaning a 160-bit hash value. SHA-2 is a "family" of hashes, available in various lengths, and consists of combined values ​​with different bit lengths, such as 256 bits. SHA-2 can include SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, SHA-512 / 256, etc.

[0135] It is evident that using hash algorithms to encrypt payment data improves data security.

[0136] In some possible designs, the payment data is processed using the standard SHA-2 algorithm to generate a target character sequence of N characters.

[0137] For example, with N=32, the generated target character sequence is "89090dfffdiojjf90328394ukxjklj90".

[0138] • Determine the salt value with N characters based on the m*n matrix and the target character sequence.

[0139] It should be noted that, since the m*n matrix contains M characters and the target character sequence contains N characters, and N is an integer multiple of M, in the process of determining the salt value, the embodiments of this application can perform N / M parallel calculations on the m*n matrix and the target character sequence, thereby improving the processing efficiency of generating the salt value through parallel computing. For example, when N is 32 and M is 16, two calculations can be performed in parallel.

[0140] To determine the salt value with N characters based on an m*n matrix and a target character sequence, the following steps can be included:

[0141] ◆ Obtain the i-th character (i∈{1,2,...,N}) from the N characters of the target character sequence (i.e., the first character), and perform a modulo operation between the i-th character and M to obtain the remainder.

[0142] In some possible designs, performing a modulo operation between the i-th character and M can include the following steps: converting the i-th character into a decimal value using the ASCII code table, and then performing a modulo operation between the decimal value and M.

[0143] For example, with M = 16 and N = 32, when the 4x4 matrix is...

[0144]

[0145] When the target character sequence is “89090dfffdiojjf90328394ukxjklj90”, first extract the first character “8” from the target character sequence, convert the character “8” to a decimal value of 56 using the ASCII code table, and then perform a modulo operation between 56 and 16 to obtain the remainder 8.

[0146] ◆Determine the character corresponding to the remainder from the M characters of an m*n matrix.

[0147] It should be noted that the character corresponding to this remainder can be understood as the salt mask used to generate the salt value.

[0148] This application embodiment can extract the character corresponding to the remainder from M characters of an m*n matrix in a certain order. Since the m*n matrix has m rows and n columns, it can be processed in either row-first or column-first order.

[0149] For example, after obtaining the remainder 8 in the above example, if the order is row-first and then column-first, the character corresponding to the remainder 8 is taken from the 16 characters of the 4*4 matrix, which is "H", and the salt value mask is "H"; if the order is column-first and then row-first, the character corresponding to the remainder 8 is taken from the 16 characters of the 4*4 matrix, which is "6", and the salt value mask is "6".

[0150] ◆Determine the i-th character among the N characters for the salt value based on the i-th character and the character corresponding to the remainder.

[0151] In one possible design, determining the i-th character among the N characters for the salt value based on the i-th character and the character corresponding to the remainder can include the following steps:

[0152] The i-th character is converted into an eight-bit binary value, X, using the ASCII code table, and the character corresponding to the remainder is converted into an eight-bit binary value, Y.

[0153] X and Y are XORed to obtain Z;

[0154] Convert Z to a character using the ASCII code table to obtain the i-th character among the N characters of the salt value.

[0155] For example, after obtaining the character "H" corresponding to the remainder 8 in the above example, the first character "8" in the target character sequence and the character "H" corresponding to the remainder 8 are XORed to obtain the first character of the salt value. Similarly, the above steps are executed sequentially to process the remaining 31 characters in the target character sequence to obtain the remaining 31 characters of the salt value.

[0156] As can be seen, through the above-described salt value generation algorithm, this application embodiment uses the PIN code to generate a random salt value for each user (indicated by the user identification information) and each payment data, so that different users use different salt values ​​and each payment data uses different salt values, thereby helping to ensure the flexibility of payment processing (authentication processing, etc.).

[0157] 7) Signature information generation

[0158] As can be seen from the above, electronic devices mix payment data with a salt value to generate signature information, and then have the server authenticate the signature information accordingly. Finally, when the authentication is successful, the mobile payment for the selected business type is completed.

[0159] Since the salt value generated based on the PIN code in this embodiment is a random value, compared with a fixed salt value, a random salt value can effectively avoid being exposed or cracked, thereby improving the security of payment processing.

[0160] In some possible designs, determining signature information based on salt value and payment data may include the following steps: processing the salt value and payment data using a hash algorithm to generate signature information.

[0161] For example, salt values ​​and payment data are processed using the standard SHA-2 algorithm to generate signature information.

[0162] 8) PIN-based payment processing flow

[0163] Based on the above, the following examples illustrate the PIN code-based authentication process from the perspectives of electronic devices and servers.

[0164] For example, the following steps can be performed on an electronic device:

[0165] • Control the function to generate a PIN code when it is called, such as the payment function or VPA function;

[0166] It should be noted that when functions such as payment functions or VPA functions are called, it can be understood that the business type needs to perform payment (mobile payment / transaction, etc.).

[0167] For example, a user selects a service type (such as mobile phone top-up) on a mobile wallet platform or payment application, and generates a PIN code when clicking the payment button to execute the transaction.

[0168] In addition, the PIN code is generated based on the user identification information and the function address in the operating system's dynamic library file. For details, please refer to the content in "4) Personal Identification Code" above.

[0169] Convert the PIN code into an m*n matrix.

[0170] It should be noted that for details on PIN code conversion, please refer to the "PIN Code Conversion Processing" section above.

[0171] The payment data passed to this function is processed using the SHA-2 algorithm to generate a sequence of N characters.

[0172] It should be noted that for details on payment data processing, please refer to the content in "6) Salt Value Generation Algorithm" above.

[0173] • Perform operations on the sequence with an m*n matrix to generate a salt value with N characters;

[0174] It should be noted that the generation of salt value can be found in the section "6) Salt Value Generation Algorithm" above.

[0175] • Process the payment data and the salt value using the SHA-2 algorithm to generate signature information and send an authentication request message to the server.

[0176] It should be noted that this authentication request message can be used to request the server to authenticate the signature information to determine the security of the transaction type payment (this transaction).

[0177] Alternatively, the authentication request message can be transmitted via Hypertext Transfer Protocol over Secure Socket layer (HTTPS).

[0178] The authentication request message may include signature information, user identification information, and payment data.

[0179] • Obtain the authentication result from the server.

[0180] It should be noted that the authentication result includes whether the signature information passes / satisfies the consistency check or fails / does not satisfy the consistency check.

[0181] If the authentication result indicates that the signature information passes / satisfies the consistency check, then the payment for this business type (this transaction) is determined to be secure, meaning that this payment behavior is a secure behavior, and the payment for this business type (i.e., the execution of this transaction) is executed, thereby completing the authentication process for this transaction.

[0182] If the authentication result indicates that the signature information fails / does not meet the consistency check, then the current business type payment (this transaction) is determined to be insecure, meaning that the current payment behavior is an insecure behavior, and the current business type payment is cancelled (i.e., the current transaction is cancelled), thereby completing the authentication process for this transaction.

[0183] Similarly, for the server, the following steps can be performed:

[0184] ◆ Obtain the authentication request message from the electronic device.

[0185] It should be noted that this authentication request message can be used to request the server to authenticate the signature information in the authentication request message to determine the security of the transaction type payment (this transaction). This authentication request message may include the signature information, user identification information, and payment data.

[0186] It should be noted that since the authentication request message can contain user identification information, i.e., user identification information is uploaded by electronic devices, and the server itself can be configured with the operating system's dynamic library files, as well as the functions and function addresses of the dynamic library files, the server can generate a PIN code in the same way as described above. That is, the PIN code can be generated based on the user identification information contained in the authentication request message and the function addresses on the operating system's dynamic library files. For details, please refer to the content in "4) Personal Identification Code" above.

[0187] ◆ Convert the PIN code into an m*n matrix

[0188] It should be noted that for details on PIN code conversion, please refer to the "PIN Code Conversion Processing" section above.

[0189] ◆Process the payment data in the authentication request message using the SHA-2 algorithm to generate a sequence of N characters.

[0190] It should be noted that for details on payment data processing, please refer to the content in "6) Salt Value Generation Algorithm" above.

[0191] ◆ Perform operations on the sequence with an m*n matrix to generate a salt value with N characters;

[0192] It should be noted that the generation of salt value can be found in the section "6) Salt Value Generation Algorithm" above.

[0193] ◆ The payment data and the salt value are processed using the SHA-2 algorithm to generate the target signature information.

[0194] ◆ Compare the signature information with the target signature information to obtain the authentication result, and send the authentication result to the electronic device.

[0195] It should be noted that the embodiments of this application can use a consistency algorithm to compare the signature information and the target signature information. The authentication result includes whether the signature information and the target signature information are consistent (i.e., the signature information passes / satisfies the consistency check) or whether the signature information and the target signature information are inconsistent (i.e., the signature information fails / does not satisfy the consistency check).

[0196] If the signature information and the target signature information are consistent, the current business type payment (this transaction) is determined to be secure, that is, the current payment behavior is a secure behavior, and the current business type payment (i.e., the current transaction) is executed, thereby completing the authentication process for this transaction.

[0197] If the signature information and the target signature information do not meet the consistency requirement, the current business type payment (this transaction) is determined to be insecure, that is, the current payment behavior is an insecure behavior, and the current business type payment is cancelled (i.e., the current transaction is cancelled), thereby completing the authentication process for this transaction.

[0198] As can be seen, in the PIN code-based payment processing flow of this application embodiment, since the PIN code is generated based on the user identification information and the function address on the operating system's dynamic library file, the PIN code is not directly transmitted between the electronic device and the server. Therefore, it is beneficial to avoid the PIN code being exposed and discovered, and to ensure the security of payment processing.

[0199] At the same time, a random salt value is generated for each user and each payment data using the PIN code, so that different users use different salt values ​​and each payment data uses different salt values, which helps to ensure the flexibility of payment processing.

[0200] In addition, using PIN codes to generate random salt values ​​allows electronic devices and servers to maintain only the PIN codes, rather than storing a large number of salt values. This not only helps prevent the salt values ​​from being exposed or cracked, but also facilitates the construction of more secure authentication processes and richer payment protection processes for various business types, thereby improving the security of payment processing.

[0201] In summary, in order to improve the security of payment processing, an example of a payment processing method according to an embodiment of this application will be described below using an electronic device as an example.

[0202] For example, such as Figure 3 The diagram shown is a flowchart illustrating a payment processing method according to an embodiment of this application, which specifically includes the following steps:

[0203] S310. Obtain the personal identification code and payment data. The personal identification code has M characters, and the payment data is used to represent the data generated when making a payment for the target business type. M is an integer greater than 1.

[0204] It should be noted that detailed explanations regarding "personal identification code" and "payment data" can be found in the above description, and will not be repeated here.

[0205] In some possible designs, a Personal Identification Code (PIC) can be generated based on user identification information and function addresses in the operating system's dynamic library files. It is understood that obtaining a PIC may include the following steps: obtaining user identification information and the operating system's dynamic library files, and generating a PIC based on the user identification information and function addresses in the dynamic library files.

[0206] The function addresses on the dynamic library file can be used to represent the functions that are scheduled.

[0207] As can be seen, since the PIN code is generated based on the user identification information and the function address on the dynamic library file, the PIN code is not directly transmitted between the electronic device and the server. Only the user identification information is transmitted, which helps to avoid the PIN code being exposed and discovered.

[0208] In addition, since different users (i.e., different user identification information) and different versions of dynamic library files will generate different PIN codes, the PIN code in this application embodiment can be used to uniquely identify users and / or dynamic library files.

[0209] S320. Determine a salt value with N characters based on the personal identification code and payment data, where N is an integer multiple of M.

[0210] It should be noted that detailed information regarding "salinity" can be found in the above description, and will not be repeated here.

[0211] In some possible designs, determining a salt value with N characters based on a personal identification code and payment data may include the following steps: converting the personal identification code into an m*n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1; and determining a salt value with N characters based on the m*n matrix and payment data.

[0212] The m*n matrix can be used as a mask for the salt value.

[0213] It should be noted that an m*n matrix can also be understood as a table (table) with m rows and n columns, and there are no specific restrictions on it.

[0214] It is evident that the purpose of converting the PIN code into an m*n matrix is ​​as follows: Since an m*n matrix can have m rows and n columns, in the subsequent salt value generation process, the characters corresponding to the remainders in the m*n matrix can be extracted as salt value masks using either the row-first-column or column-first-row order. In other words, the m*n matrix is ​​used as a salt value mask, thereby generating different salt values ​​through different orders, which in turn improves the flexibility of payment processing (authentication processing, etc.).

[0215] Specifically, converting a personal identification code into an m*n matrix can include the following steps: arranging the M characters from the PIN code in a row-first-column or column-first-row order to generate an m*n matrix, or arranging the M characters from the PIN code in the order of their arrangement to generate an M-order vector.

[0216] Specifically, determining a salt value with N characters based on an m*n matrix and payment data can include the following steps: processing the payment data using a hash algorithm to generate a target character sequence with N characters; and determining a salt value with N characters based on the m*n matrix and the target character sequence.

[0217] It is evident that using hash algorithms to encrypt payment data improves data security.

[0218] Furthermore, since the m*n matrix contains M characters and the target character sequence contains N characters, and N is an integer multiple of M, this embodiment of the application can perform N / M parallel calculations on the m*n matrix and the target character sequence during the salt value determination process, thereby improving the processing efficiency of salt value generation through parallel computation. For example, when N is 32 and M is 16, two parallel calculations can be performed.

[0219] Furthermore, processing the payment data using a hash algorithm to generate a target character sequence of N characters can include the following steps: processing the payment data using the standard SHA-2 algorithm to generate a target character sequence of N characters.

[0220] As can be seen, it is easy to implement using the standard SHA-2 algorithm.

[0221] Furthermore, determining the salt value with N characters based on the m*n matrix and the target character sequence can include: obtaining the first character from the N characters of the target character sequence, and performing a modulo operation between the first character and M to obtain the first remainder; determining the character corresponding to the first remainder from the M characters of the m*n matrix to obtain the second character; and determining the third character as the salt value based on the first character and the second character.

[0222] The character corresponding to the first remainder can be understood as the salt mask.

[0223] The modulo operation between the first character and M can include the following steps: converting the first character into a decimal value using the ASCII code table; performing a modulo operation between the decimal value and M, thereby realizing the modulo processing of the first character through the conversion of the ASCII code table.

[0224] Determining the character corresponding to the first remainder from the M characters of an m*n matrix can include the following steps: extracting the character corresponding to the first remainder from the M characters of the m*n matrix in either row-first-column or column-first-row order to improve flexibility.

[0225] The process of determining the third character as the salt value based on the first and second characters can include the following steps: converting the first character into an eight-bit binary value using the ASCII code table to obtain the first value; converting the second character into an eight-bit binary value using the ASCII code table to obtain the second value; performing an XOR operation on the first and second values ​​to obtain the third value; and converting the third value into a character using the ASCII code table to obtain the third character as the salt value. This process achieves the XOR operation on the first and second characters through ASCII code table conversion, thereby generating the salt value.

[0226] As can be seen, by taking the modulo operation between each of the N characters in the target character sequence and M, it is easy to determine the character corresponding to each character in the m*n matrix, so that the corresponding character can be used as a mask for salt value generation.

[0227] S330. Determine the signature information based on the salt value and payment data.

[0228] In some possible designs, determining signature information based on salt value and payment data may include the following steps: processing the salt value and payment data using a hash algorithm to generate signature information.

[0229] As can be seen, the salt value and payment data are merged and encrypted through hash algorithm processing to generate signature information, thus ensuring data security.

[0230] S340. Send an authentication request message to the server. The authentication request message is used to request the server to authenticate the signature information to determine the security of payment processing for the target business type.

[0231] In some possible designs, after S340, the following steps may also be included: obtaining the authentication result from the server.

[0232] It should be noted that the authentication result includes whether the signature information passes / satisfies the consistency check or fails / does not satisfy the consistency check.

[0233] If the authentication result indicates that the signature information passes / satisfies the consistency check, then the payment for this business type (this transaction) is determined to be secure, meaning that this payment behavior is a secure behavior, and the payment for this business type (i.e., the execution of this transaction) is executed, thereby completing the authentication process for this transaction.

[0234] If the authentication result indicates that the signature information fails / does not meet the consistency check, then the current business type payment (this transaction) is determined to be insecure, meaning that the current payment behavior is an insecure behavior, and the current business type payment is cancelled (i.e., the current transaction is cancelled), thereby completing the authentication process for this transaction.

[0235] As can be seen, the embodiments of this application introduce a new payment processing flow, namely payment processing based on personal identification codes. By using personal identification codes to generate random salt values ​​for each user and each payment data, different salt values ​​are used for different users and different salt values ​​are used for each payment data, thereby improving the flexibility of payment processing.

[0236] In addition, by using personal identification codes to generate random salt values, electronic devices only need to maintain PIN codes instead of storing a large number of salt values. This helps to prevent salt values ​​from being exposed or cracked, and in turn, it helps to build more secure authentication processes and more diverse payment protection logic for different business types, thereby improving the security of payment processing.

[0237] The following describes another payment processing method according to an embodiment of this application, using a server as an example.

[0238] For example, such as Figure 4 The diagram shown is a flowchart illustrating a payment processing method according to an embodiment of this application, which specifically includes the following steps:

[0239] S410. Obtain an authentication request message from an electronic device. The authentication request message is used to request authentication of the signature information in the authentication request message to determine the security of payment processing for the target business type.

[0240] It should be noted that detailed explanations regarding "authentication request messages" can be found in the above description, and will not be repeated here.

[0241] The authentication request message may include signature information, user identification information, and payment data.

[0242] S420. Determine the personal identification code based on the authentication request message. The personal identification code has M characters, where M is an integer greater than 1.

[0243] It should be noted that detailed explanations regarding "personal identification code" and "payment data" can be found in the above description, and will not be repeated here.

[0244] In some possible designs, the personal identification code can be generated based on the user identification information in the authentication request message and the function addresses on the operating system's dynamic library files.

[0245] It is understandable that determining a personal identification code based on an authentication request message may include the following steps: generating a personal identification code based on the user identification information in the authentication request message and the function addresses on the operating system's dynamic library files.

[0246] As can be seen, since the PIN code is generated based on the user identification information and the function address on the dynamic library file, the PIN code is not directly transmitted between the electronic device and the server. Only the user identification information is transmitted, which helps to avoid the PIN code being exposed and discovered.

[0247] In addition, since different users (i.e., different user identification information) and different versions of dynamic library files will generate different PIN codes, the PIN code in this application embodiment can be used to uniquely identify users and / or dynamic library files.

[0248] S430. Determine a salt value with N characters based on the personal identification code and the payment data in the authentication request message. The payment data is used to represent the data generated when making a payment for the target business type, and N is an integer multiple of M.

[0249] In some possible designs, determining the salt value with N characters based on the personal identification code and the payment data in the authentication request message in S430 may include the following steps: converting the personal identification code into an m*n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1; and determining the salt value with N characters based on the m*n matrix and the payment data.

[0250] It is evident that the purpose of converting the PIN code into an m*n matrix is ​​as follows: Since an m*n matrix can have m rows and n columns, in the subsequent salt value generation process, the characters corresponding to the remainders in the m*n matrix can be extracted as salt value masks using either the row-first-column or column-first-row order. In other words, the m*n matrix is ​​used as a salt value mask, thereby generating different salt values ​​through different orders, which in turn improves the flexibility of payment processing (authentication processing, etc.).

[0251] In some possible designs, converting a personal identification code into an m*n matrix can include the following steps: arranging the M characters from the PIN code in a row-first-column or column-first-row order to generate an m*n matrix, or arranging the M characters from the PIN code in the order of their arrangement to generate an M-order vector.

[0252] In some possible designs, determining a salt value with N characters based on an m*n matrix and payment data can include: processing the payment data using a hash algorithm to generate a target character sequence with N characters; and determining a salt value with N characters based on the m*n matrix and the target character sequence.

[0253] It is evident that using hash algorithms to encrypt payment data improves data security.

[0254] Furthermore, since the m*n matrix contains M characters and the target character sequence contains N characters, and N is an integer multiple of M, this embodiment of the application can perform N / M parallel calculations on the m*n matrix and the target character sequence during the salt value determination process, thereby improving the processing efficiency of salt value generation through parallel computation. For example, when N is 32 and M is 16, two parallel calculations can be performed.

[0255] In some possible designs, processing payment data using a hash algorithm to generate a target character sequence of N characters may include the following steps: processing payment data using the standard SHA-2 algorithm to generate a target character sequence of N characters.

[0256] As can be seen, it is easy to implement using the standard SHA-2 algorithm.

[0257] In some possible designs, determining a salt value with N characters based on an m*n matrix and a target character sequence may include the following steps: obtaining the first character from the N characters of the target character sequence and performing a modulo operation between the first character and M to obtain the first remainder; determining the character corresponding to the first remainder from the M characters of the m*n matrix to obtain the second character; and determining the third character as the salt value based on the first and second characters.

[0258] The character corresponding to the first remainder can be understood as the salt mask.

[0259] In some possible designs, performing a modulo operation between the first character and M can include the following steps: converting the first character into a decimal value using the ASCII code table; performing a modulo operation between the decimal value and M, thereby achieving the modulo processing of the first character through the conversion of the ASCII code table.

[0260] In some possible designs, determining the character corresponding to the first remainder from the M characters of an m*n matrix can include the following steps: extracting the character corresponding to the first remainder from the M characters of the m*n matrix in either row-first-column or column-first-row order to improve flexibility.

[0261] In some possible designs, determining the third character as the salt value based on the first and second characters may include the following steps: converting the first character into an eight-bit binary value using the ASCII code table to obtain the first value; converting the second character into an eight-bit binary value using the ASCII code table to obtain the second value; performing an XOR operation on the first and second values ​​to obtain the third value; and converting the third value into a character using the ASCII code table to obtain the third character as the salt value.

[0262] As can be seen, by taking the modulo operation between each of the N characters in the target character sequence and M, it is easy to determine the character corresponding to each character in the m*n matrix, so that the corresponding character can be used as a mask for salt value generation.

[0263] S440. Determine the target signature information based on the salt value and payment data.

[0264] In some possible designs, determining signature information based on salt value and payment data may include the following steps: processing the salt value and payment data using a row hash algorithm to generate signature information.

[0265] As can be seen, the salt value and payment data are merged and encrypted through hash algorithm processing to generate signature information, thus ensuring data security.

[0266] S450. Compare the consistency between the signature information and the target signature information to obtain a comparison result, which is used to determine the security of payment processing for the target business type.

[0267] It should be noted that the embodiments of this application can use a consistency algorithm to compare the signature information and the target signature information. The authentication result includes whether the signature information and the target signature information are consistent (i.e., the signature information passes / satisfies the consistency check) or whether the signature information and the target signature information are inconsistent (i.e., the signature information fails / does not satisfy the consistency check).

[0268] If the signature information and the target signature information are consistent, the current business type payment (this transaction) is determined to be secure, that is, the current payment behavior is a secure behavior, and the current business type payment (i.e., the current transaction) is executed, thereby completing the authentication process for this transaction.

[0269] If the signature information and the target signature information do not meet the consistency requirement, the current business type payment (this transaction) is determined to be insecure, that is, the current payment behavior is an insecure behavior, and the current business type payment is cancelled (i.e., the current transaction is cancelled), thereby completing the authentication process for this transaction.

[0270] S460: Send the comparison results to the electronic device.

[0271] It should be noted that, Figure 4 For details not covered in the above, please refer to the above. Figure 3 The content and other related information will not be elaborated upon here.

[0272] As can be seen, the embodiments of this application introduce a new payment processing flow, namely payment processing based on personal identification codes. By using personal identification codes to generate random salt values ​​for each user and each payment data, different salt values ​​are used for different users and different salt values ​​are used for each payment data, thereby improving the flexibility of payment processing.

[0273] In addition, by using personal identification codes to generate random salt values, servers only need to maintain PIN codes instead of storing a large number of salt values. This helps prevent salt values ​​from being exposed or cracked, and in turn, it facilitates the construction of more secure authentication processes and payment protection logic for richer business types, thereby improving the security of payment processing.

[0274] The foregoing mainly describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the electronic device or server includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should recognize that the methods, functions, modules, units, or steps described in conjunction with the embodiments provided herein can be implemented in hardware or a combination of hardware and computer software. Whether a method, function, module, unit, or step is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described methods, functions, modules, units, or steps for each specific application, but such implementation should not be considered beyond the scope of this application.

[0275] The embodiments of this application can divide functional units / modules according to the above method examples. For example, each function can be divided into a separate functional unit / module, or two or more functions can be integrated into one functional unit / module. The integrated functional unit / module can be implemented in hardware or in software.

[0276] It should be noted that the division of functional units / modules in this embodiment is illustrative and is only a logical functional division. In actual implementation, there may be other division methods.

[0277] When using integrated units, Figure 5 This is a functional unit block diagram of a payment processing device according to an embodiment of this application. The payment processing device 500 includes: an acquisition unit 510, a determination unit 520, and a sending unit 530.

[0278] It should be noted that the acquisition unit 510 can be a module unit used for transmitting and receiving signals, data, information, etc., and there are no specific restrictions on it.

[0279] The determining unit 520 can be a module unit used to process signal data, information, etc., and there are no specific restrictions on it.

[0280] The transmitting unit 530 can be a module unit used to process signal data, information, etc., and there are no specific limitations on it.

[0281] In some possible designs, the acquisition unit 510 and the transmission unit 530 can be integrated into one unit or they can be two separate units.

[0282] For example, the acquisition unit 510 and the transmission unit 530 can be integrated into a communication unit, which can be a communication interface, transceiver, transceiver circuit, etc.

[0283] In some possible designs, the determining unit 520 may be integrated into the processing unit. The processing unit may be a processor or controller, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processing unit may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0284] In some possible designs, the payment processing device 500 may also include a storage unit for storing computer programs or instructions executed by the payment processing device 500. This storage unit may be a memory.

[0285] In some possible designs, the payment processing device 500 can be a chip / chip module / processor / electronic device.

[0286] In specific implementation, the acquisition unit 510, the determination unit 520, and the sending unit 530 are used to perform the steps described in the above method embodiments. A detailed explanation follows.

[0287] The acquisition unit 510 is used to acquire personal identification code and payment data. The personal identification code has M characters, and the payment data is used to represent the data generated when making payment for the target business type, where M is an integer greater than 1.

[0288] The determining unit 520 is used to determine a salt value with N characters based on the personal identification code and payment data, where N is an integer multiple of M;

[0289] The determining unit 520 is also used to determine signature information based on the salt value and payment data;

[0290] The sending unit 530 is used to send an authentication request message to the server. The authentication request message is used to request the server to authenticate the signature information to determine the security of the payment processing for the target business type.

[0291] It is evident that payment processing based on personal identification codes utilizes these codes to generate random salt values ​​for each user and each payment data point, resulting in different salt values ​​for different users and for each payment data point, thereby enhancing the flexibility of payment processing.

[0292] In addition, by using personal identification codes to generate random salt values, the payment processing device 500 only needs to maintain PIN codes instead of storing a large number of salt values. This helps to prevent the salt values ​​from being exposed or cracked, and in turn, it helps to build more secure authentication processes and payment protection logic for richer business types to improve the security of payment processing.

[0293] It should be noted that, Figure 5 The specific implementation of each operation in the embodiments can be found in the description of the method embodiments shown above, and will not be repeated here.

[0294] In some possible designs, the personal identification code is generated based on user identification information and function addresses in the operating system's dynamic library files.

[0295] In some possible designs, in determining a salt value with N characters based on a personal identification code and payment data, the determining unit 520 is used to: convert the personal identification code into an m*n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1; and determine a salt value with N characters based on the m*n matrix and payment data.

[0296] In some possible designs, in converting a personal identification code into an m*n matrix, the determining unit 520 is used to: arrange the M characters in the PIN code in a row-first-column or column-first-row order to generate an m*n matrix, or arrange the M characters in the PIN code in the order of their arrangement to generate an M-order vector.

[0297] In some possible designs, in determining a salt value with N characters based on an m*n matrix and payment data, the determining unit 520 is used to: process the payment data using a hash algorithm to generate a target character sequence with N characters; and determine a salt value with N characters based on the m*n matrix and the target character sequence.

[0298] In some possible designs, in terms of processing payment data using a hash algorithm to generate a target character sequence of N characters, the determining unit 520 is used to: process the payment data using the standard SHA-2 algorithm to generate a target character sequence of N characters.

[0299] In some possible designs, in determining a salt value with N characters based on an m*n matrix and a target character sequence, the determining unit 520 is used to: obtain the first character from the N characters of the target character sequence, and perform a modulo operation between the first character and M to obtain a first remainder; determine the character corresponding to the first remainder from the M characters of the m*n matrix to obtain a second character; and determine a third character as the character to be used as the salt value based on the first character and the second character.

[0300] In some possible designs, in terms of performing a modulo operation between the first character and M, the determining unit 520 is used to: convert the first character into a decimal value through the ASCII code table; and perform a modulo operation between the decimal value and M, thereby realizing the modulo processing of the first character through the conversion of the ASCII code table.

[0301] In some possible designs, in determining the character corresponding to the first remainder from the M characters of an m*n matrix, the determining unit 520 is used to: extract the character corresponding to the first remainder from the M characters of the m*n matrix in a row-first-column or column-first-row order to improve flexibility.

[0302] In some possible designs, in determining the third character as the salt value based on the first and second characters, the determining unit 520 is configured to: convert the first character into an eight-bit binary value using the ASCII code table to obtain a first value; convert the second character into an eight-bit binary value using the ASCII code table to obtain a second value; perform an XOR operation on the first and second values ​​to obtain a third value; and convert the third value into a character using the ASCII code table to obtain the third character as the salt value.

[0303] In some possible designs, in determining signature information based on salt value and payment data, the determining unit 520 is used to: process the salt value and payment data using a hash algorithm to generate signature information.

[0304] In some possible designs, the acquisition unit 510 is also used to: acquire the authentication result from the server.

[0305] When using integrated units, Figure 6 This is a functional unit block diagram of another payment processing device according to an embodiment of this application. The payment processing device 600 includes: an acquisition unit 610, a determination unit 620, a comparison unit 630, and a sending unit 640.

[0306] It should be noted that the acquisition unit 610 can be a module unit used for transmitting and receiving signals, data, information, etc., and there are no specific restrictions on it.

[0307] The determining unit 620 can be a module unit used to process signal data, information, etc., and there are no specific limitations on it.

[0308] The comparison unit 630 can be a module unit used to process signal data, information, etc., and there are no specific limitations on it.

[0309] The transmitting unit 640 can be a module unit used to process signal data, information, etc., and there are no specific limitations on it.

[0310] In some possible designs, the acquisition unit 610 and the transmission unit 640 can be integrated into one unit or they can be two separate units.

[0311] For example, the acquisition unit 610 and the transmission unit 640 can be integrated into a communication unit, which can be a communication interface, transceiver, transceiver circuit, etc.

[0312] In some possible designs, the determining element 620 and the comparing element 630 can be integrated into one element or they can be two separate elements.

[0313] For example, the determining unit 620 and the comparing unit 630 can be integrated into the processing unit. The processing unit can be a processor or controller, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processing unit can also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0314] In some possible designs, the payment processing device 600 may also include a storage unit for storing computer programs or instructions executed by the payment processing device 600. This storage unit may be a memory.

[0315] In some possible designs, the payment processing device 600 can be a chip / chip module / processor / server.

[0316] In specific implementation, the acquisition unit 610, the determination unit 620, the comparison unit 630, and the sending unit 640 are used to perform the steps described in the above method embodiments. A detailed explanation follows.

[0317] The acquisition unit 610 is used to acquire an authentication request message from an electronic device. The authentication request message is used to request authentication of the signature information in the authentication request message to determine the security of payment processing for the target business type.

[0318] The determining unit 620 is used to determine the personal identification code based on the authentication request message. The personal identification code has M characters, where M is an integer greater than 1.

[0319] The determining unit 620 is also used to determine a salt value with N characters based on the personal identification code and the payment data in the authentication request message. The payment data is used to represent the data generated when making a payment for the target business type, and N is an integer multiple of M.

[0320] The determining unit 620 is also used to determine the target signature information based on the salt value and payment data;

[0321] The comparison unit 630 is used to compare the consistency between the signature information and the target signature information to obtain a comparison result, which is used to determine the security of the payment processing of the target business type.

[0322] The transmitting unit 640 is used to transmit the comparison result to the electronic device.

[0323] It is evident that payment processing based on personal identification codes utilizes these codes to generate random salt values ​​for each user and each payment data point, resulting in different salt values ​​for different users and for each payment data point, thereby enhancing the flexibility of payment processing.

[0324] In addition, by using personal identification codes to generate random salt values, the payment processing device 600 only needs to maintain PIN codes instead of storing a large number of salt values. This helps to prevent the salt values ​​from being exposed or cracked, and in turn, it helps to build more secure authentication processes and payment protection logic for richer business types to improve the security of payment processing.

[0325] It should be noted that, Figure 6 The specific implementation of each operation in the embodiments can be found in the description of the method embodiments shown above, and will not be repeated here.

[0326] The following is a schematic diagram of the structure of an electronic device according to an embodiment of this application, such as... Figure 7 As shown. The electronic device 700 includes a processor 710, a memory 720, and a communication bus for connecting the processor 710 and the memory 720.

[0327] Processor 710 can be one or more central processing units (CPUs). When processor 710 is a CPU, the CPU can be a single-core CPU or a multi-core CPU.

[0328] The memory 720 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), and the memory 720 is used to store program code executed by the electronic device 700 and data transmitted therefrom.

[0329] The electronic device 700 also includes a communication interface for receiving and sending data.

[0330] The processor 710 in the electronic device 700 executes a computer program or instruction 721 stored in the memory 720 to implement the steps of the designed method as follows: obtaining a personal identification code and payment data, wherein the personal identification code has M characters and the payment data is used to represent the data generated when making a payment for the target business type, where M is an integer greater than 1; determining a salt value with N characters based on the personal identification code and the payment data, where N is an integer multiple of M; determining signature information based on the salt value and the payment data; and sending an authentication request message to the server, which requests the server to authenticate the signature information to determine the security of the payment processing for the target business type.

[0331] It is evident that payment processing based on personal identification codes utilizes these codes to generate random salt values ​​for each user and each payment data point, resulting in different salt values ​​for different users and for each payment data point, thereby enhancing the flexibility of payment processing.

[0332] In addition, by using personal identification codes to generate random salt values, electronic devices 700 only need to maintain PIN codes instead of storing a large number of salt values. This helps to prevent the salt values ​​from being exposed or cracked, and in turn, it helps to build more secure authentication processes and richer payment protection logic for various business types to improve the security of payment processing.

[0333] It should be noted that the specific implementation of each operation performed by the electronic device 700 can be found in the corresponding description of the method embodiment shown above, and will not be repeated here.

[0334] In some possible designs, the personal identification code is generated based on user identification information and function addresses in the operating system's dynamic library files.

[0335] In some possible designs, in determining a salt value with N characters based on a personal identification code and payment data, the determining unit 520 is used to: convert the personal identification code into an m*n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1; and determine a salt value with N characters based on the m*n matrix and payment data.

[0336] In some possible designs, in converting a personal identification code into an m*n matrix, the processor 710 in the electronic device 700 executes a computer program or instruction 721 stored in the memory 720 to implement the steps in the designed method as follows: arranging the M characters in the PIN code in a row-first-column or column-first-row order to generate an m*n matrix, or arranging the M characters in the PIN code in the order of character arrangement to generate an M-order vector.

[0337] In some possible designs, in determining a salt value with N characters based on an m*n matrix and payment data, the processor 710 in the electronic device 700 executes a computer program or instruction 721 stored in the memory 720 to implement the steps in the designed method as follows: processing the payment data with a hash algorithm to generate a target character sequence with N characters; determining a salt value with N characters based on the m*n matrix and the target character sequence.

[0338] In some possible designs, in terms of processing payment data with a hash algorithm to generate a target character sequence of N characters, the processor 710 in the electronic device 700 is used to execute a computer program or instruction 721 stored in the memory 720 to implement the steps in the designed method as follows: processing payment data with a standard SHA-2 algorithm to generate a target character sequence of N characters.

[0339] In some possible designs, in determining a salt value with N characters based on an m*n matrix and a target character sequence, the processor 710 in the electronic device 700 executes a computer program or instruction 721 stored in the memory 720 to implement the steps in the designed method as follows: obtaining the first character from the N characters of the target character sequence, and performing a modulo operation between the first character and M to obtain a first remainder; determining the character corresponding to the first remainder from the M characters of the m*n matrix to obtain a second character; and determining a third character as the character for the salt value based on the first character and the second character.

[0340] In some possible designs, in terms of performing a modulo operation between the first character and M, the processor 710 in the electronic device 700 executes a computer program or instruction 721 stored in the memory 720 to implement the steps in the designed method as follows: converting the first character into a decimal value through the ASCII code table; performing a modulo operation between the decimal value and M, thereby realizing the modulo processing of the first character through the conversion of the ASCII code table.

[0341] In some possible designs, in determining the character corresponding to the first remainder from the M characters of an m*n matrix, the processor 710 in the electronic device 700 executes a computer program or instruction 721 stored in the memory 720 to implement the steps in the designed method as follows: extracting the character corresponding to the first remainder from the M characters of the m*n matrix in a row-first-column or column-first-row order to improve flexibility.

[0342] In some possible designs, in determining the third character as the salt value based on the first and second characters, the processor 710 in the electronic device 700 executes a computer program or instruction 721 stored in the memory 720 to implement the steps in the designed method as follows: converting the first character into an eight-bit binary value through the ASCII code table to obtain a first value; converting the second character into an eight-bit binary value through the ASCII code table to obtain a second value; performing an XOR operation on the first and second values ​​to obtain a third value; and converting the third value into a character through the ASCII code table to obtain the third character as the salt value.

[0343] In some possible designs, in determining signature information based on salt value and payment data, processor 710 in electronic device 700 executes computer program or instructions 721 stored in memory 720 to implement the steps in the designed method as follows: processing salt value and payment data with a hash algorithm to generate signature information.

[0344] In some possible designs, the processor 710 in the electronic device 700 is also used to execute computer programs or instructions 721 stored in the memory 720 to implement the steps in the designed method as follows: obtaining authentication results from the server.

[0345] The following is a schematic diagram of the structure of a server according to an embodiment of this application, such as... Figure 8 As shown. The server 800 includes a processor 810, a memory 820, and a communication bus for connecting the processor 810 and the memory 820.

[0346] Processor 810 can be one or more central processing units (CPUs). When processor 810 is a CPU, the CPU can be a single-core CPU or a multi-core CPU.

[0347] The memory 820 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), and the memory 820 is used to store the program code executed by the server 800 and the data transmitted.

[0348] Server 800 also includes a communication interface for receiving and sending data.

[0349] The processor 810 in server 800 executes a computer program or instruction 821 stored in memory 820 to implement the steps of the designed method as follows: receiving an authentication request message from an electronic device, the authentication request message requesting authentication of the signature information in the authentication request message to determine the security of payment processing for the target business type; determining a personal identification code based on the authentication request message, the personal identification code having M characters, where M is an integer greater than 1; determining a salt value having N characters based on the personal identification code and payment data in the authentication request message, the payment data representing the data generated when making payment for the target business type, where N is an integer multiple of M; determining target signature information based on the salt value and payment data; comparing the consistency of the signature information and the target signature information to obtain a comparison result, the comparison result being used to determine the security of payment processing for the target business type; and sending the comparison result to the electronic device.

[0350] It is evident that payment processing based on personal identification codes utilizes these codes to generate random salt values ​​for each user and each payment data point, resulting in different salt values ​​for different users and for each payment data point, thereby enhancing the flexibility of payment processing.

[0351] In addition, by using personal identification codes to generate random salt values, the server 800 only needs to maintain PIN codes instead of storing a large number of salt values. This helps to prevent the salt values ​​from being exposed or cracked, and in turn, it helps to build more secure authentication processes and richer payment protection logic for various business types to improve the security of payment processing.

[0352] It should be noted that the specific implementation of each operation performed by server 800 can be found in the corresponding description of the method embodiment shown above, and will not be repeated here.

[0353] In some possible designs, the personal identification code can be generated based on the user identification information in the authentication request message and the function addresses on the operating system's dynamic library files.

[0354] In some possible designs, in determining a salt value with N characters based on the personal identification code and payment data in the authentication request message, the processor 810 in the server 800 executes a computer program or instruction 821 stored in the memory 820 to implement the steps in the designed method as follows: converting the personal identification code into an m*n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1; determining a salt value with N characters based on the m*n matrix and payment data.

[0355] In some possible designs, in converting a personal identification code into an m*n matrix, the processor 810 in server 800 executes a computer program or instruction 821 stored in memory 820 to implement the steps in the designed method as follows: arranging the M characters in the PIN code in a row-first-column or column-first-row order to generate an m*n matrix, or arranging the M characters in the PIN code in the order of their character arrangement to generate an M-order vector.

[0356] In some possible designs, in determining a salt value with N characters based on an m*n matrix and payment data, the processor 810 in server 800 executes a computer program or instruction 821 stored in memory 820 to implement the steps in the designed method as follows: processing the payment data with a hash algorithm to generate a target character sequence with N characters; determining a salt value with N characters based on the m*n matrix and the target character sequence.

[0357] In some possible designs, in processing payment data using a hash algorithm to generate a target character sequence of N characters, the processor 810 in server 800 executes a computer program or instruction 821 stored in memory 820 to implement the steps in the designed method as follows: processing payment data using the standard SHA-2 algorithm to generate a target character sequence of N characters.

[0358] In some possible designs, in determining a salt value with N characters based on an m*n matrix and a target character sequence, the processor 810 in server 800 executes a computer program or instruction 821 stored in memory 820 to implement the steps in the designed method as follows: obtaining the first character from the N characters of the target character sequence and performing a modulo operation between the first character and M to obtain a first remainder; determining the character corresponding to the first remainder from the M characters of the m*n matrix to obtain a second character; and determining a third character as the character to be used as the salt value based on the first character and the second character.

[0359] In some possible designs, in performing a modulo operation between the first character and M, the processor 810 in the server 800 executes a computer program or instruction 821 stored in the memory 820 to implement the steps in the designed method as follows: converting the first character into a decimal value through the ASCII code table; performing a modulo operation between the decimal value and M, thereby realizing the modulo processing of the first character through the conversion of the ASCII code table.

[0360] In some possible designs, in determining the character corresponding to the first remainder from the M characters of an m*n matrix, the processor 810 in the server 800 executes a computer program or instruction 821 stored in the memory 820 to implement the steps in the designed method as follows: extracting the character corresponding to the first remainder from the M characters of the m*n matrix in a row-first-column or column-first-row order to improve flexibility.

[0361] In some possible designs, in determining the third character as the salt value based on the first and second characters, the processor 810 in the server 800 executes a computer program or instruction 821 stored in the memory 820 to implement the steps in the designed method as follows: converting the first character into an eight-bit binary value using the ASCII code table to obtain a first value; converting the second character into an eight-bit binary value using the ASCII code table to obtain a second value; performing an XOR operation on the first and second values ​​to obtain a third value; and converting the third value into a character using the ASCII code table to obtain the third character as the salt value.

[0362] In some possible designs, in determining signature information based on salt value and payment data, processor 810 in server 800 executes computer program or instructions 821 stored in memory 820 to implement the steps in the designed method as follows: processing salt value and payment data using a row hash algorithm to generate signature information.

[0363] This application also provides a computer-readable storage medium storing a computer program or instructions that, when executed, implement the steps of the method designed in the above embodiments.

[0364] This application also provides a computer program product, including a computer program or instructions, wherein the computer program or instructions, when executed, implement the steps in the method designed in the above embodiments.

[0365] For example, the computer program product may be a software installation package.

[0366] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0367] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0368] The various devices and products described in the above embodiments include modules / units, which may be software modules / units, hardware modules / units, or may be partly software modules / units and partly hardware modules / units. For example, for various devices or products that apply or integrate chips, each module / unit can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs running on the integrated processor inside the chip, while the remaining modules / units can be implemented using hardware methods such as circuits; for various devices or products that apply or integrate chip modules, each module / unit can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, at least some modules / units can be implemented using software programs running on the integrated processor inside the chip module, while the remaining modules / units can be implemented using hardware methods such as circuits; for various devices or products that apply or integrate terminals, each module / unit can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal, or at least some modules / units can be implemented using software programs running on the integrated processor inside the terminal, while the remaining modules / units can be implemented using hardware methods such as circuits.

[0369] Those skilled in the art should understand that the functions of the methods, steps, or related modules / units described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product, or by a processor executing computer program instructions. The computer program product includes at least one computer program instruction, which can be composed of corresponding software modules. These software modules can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, portable hard disk, read-only optical disc (CD-ROM), or any other form of storage medium well known in the art. The computer program instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer program instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media, or semiconductor media (e.g., SSDs).

[0370] The modules / units included in the various devices or products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of software and hardware modules / units. For example, for devices or products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits; or, some of their modules / units can be implemented using software programs that run on a processor integrated within the chip, while other (if any) modules / units can be implemented using hardware methods such as circuits. The same principle applies to devices or products applied to or integrated into chip modules, or devices or products applied to or integrated into terminals.

[0371] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A payment processing method, characterized in that, include: Obtain a personal identification code and payment data. The personal identification code has M characters, and the payment data is used to represent the data generated when making a payment for the target business type, where M is an integer greater than 1. A salt value with N characters is determined based on the personal identification code and the payment data, where N is an integer multiple of M. Specifically, the personal identification code is converted into an m×n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1. The payment data is processed using a hash algorithm to generate a target character sequence with N characters. The first character from the N characters of the target character sequence is obtained, and a modulo operation is performed between the first character and M to obtain a first remainder. The character corresponding to the first remainder is determined from the M characters of the m×n matrix to obtain a second character. A third character is determined based on the first character and the second character to serve as the salt value. The signature information is determined based on the salt value and the payment data; Send an authentication request message to the server, the authentication request message being used to request the server to authenticate the signature information to determine the security of payment processing for the target business type.

2. The method according to claim 1, characterized in that, The personal identification code is generated based on user identification information and function addresses in the operating system's dynamic library files.

3. The method according to claim 1, characterized in that, The step of determining the third character as the salt value based on the first character and the second character includes: The first character is converted into an eight-bit binary value using the ASCII code table to obtain the first value. The second character is converted into an eight-bit binary value using the ASCII code table to obtain the second value. The first value and the second value are XORed to obtain the third value; The third value is converted into a character using the ASCII code table to obtain the third character, which is then used as the salt value.

4. The method according to claim 1, characterized in that, The step of determining the signature information based on the salt value and the payment data includes: The salt value and the payment data are processed using a hash algorithm to generate the signature information.

5. A payment processing method, characterized in that, include: Obtain an authentication request message from an electronic device, the authentication request message being used to request authentication of the signature information in the authentication request message to determine the security of payment processing for the target business type; The personal identification code is determined based on the authentication request message. The personal identification code has M characters, where M is an integer greater than 1. A salt value with N characters is determined based on the personal identification code and the payment data in the authentication request message. The payment data represents the data generated when making a payment for the target business type, where N is an integer multiple of M. Specifically, the personal identification code is converted into an m×n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1. The payment data is then processed using a hash algorithm to generate a target character sequence with N characters. The first character from the N characters of the target character sequence is obtained, and a modulo operation is performed between the first character and M to obtain a first remainder. The character corresponding to the first remainder is determined from the M characters of the m×n matrix to obtain a second character. A third character is determined based on the first character and the second character to serve as the salt value. The target signature information is determined based on the salt value and the payment data; The consistency between the signature information and the target signature information is compared to obtain a comparison result, which is used to determine the security of payment processing for the target business type. The comparison result is sent to the electronic device.

6. The method according to claim 5, characterized in that, The personal identification code is generated based on the user identification information in the authentication request message and the function addresses on the operating system's dynamic library files.

7. The method according to claim 5, characterized in that, The step of determining the third character as the salt value based on the first character and the second character includes: The first character is converted into an eight-bit binary value using the ASCII code table to obtain the first value. The second character is converted into an eight-bit binary value using the ASCII code table to obtain the second value. The first value and the second value are XORed to obtain the third value; The third value is converted into a character using the ASCII code table to obtain the third character, which is then used as the salt value.

8. A payment processing device, characterized in that, include: The acquisition unit is used to acquire a personal identification code and payment data. The personal identification code has M characters, and the payment data is used to represent the data generated when making a payment for a target business type, where M is an integer greater than 1. The determining unit is configured to determine a salt value with N characters based on the personal identification code and the payment data, where N is an integer multiple of M. Specifically, the personal identification code is converted into an m×n matrix, where the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1. The payment data is processed using a hash algorithm to generate a target character sequence with N characters. The first character is obtained from the N characters of the target character sequence, and a modulo operation is performed between the first character and M to obtain a first remainder. The character corresponding to the first remainder is determined from the M characters of the m×n matrix to obtain a second character. A third character is determined based on the first character and the second character to serve as the salt value. The determining unit is further configured to determine signature information based on the salt value and the payment data; The sending unit is used to send an authentication request message to the server, the authentication request message being used to request the server to authenticate the signature information to determine the security of the payment processing for the target business type.

9. A payment processing device, characterized in that, include: The acquisition unit is used to acquire an authentication request message from an electronic device, wherein the authentication request message is used to request authentication of the signature information in the authentication request message to determine the security of payment processing for the target business type. The determining unit is configured to determine a personal identification code based on the authentication request message, wherein the personal identification code has M characters, where M is an integer greater than 1; The determining unit is further configured to determine a salt value with N characters based on the personal identification code and the payment data in the authentication request message, wherein the payment data represents the data generated when making payment for the target business type, and N is an integer multiple of M, wherein the personal identification code is converted into an m×n matrix, the product of m and n equals M, m is an integer greater than 1, and n is an integer greater than or equal to 1; the payment data is processed by a hash algorithm to generate a target character sequence with N characters; the first character is obtained from the N characters of the target character sequence, and the first character is modulo M to obtain a first remainder; the character corresponding to the first remainder is determined from the M characters of the m×n matrix to obtain a second character; and a third character is determined based on the first character and the second character to serve as the character for the salt value. The determining unit is further configured to determine target signature information based on the salt value and the payment data; A comparison unit is used to compare the consistency between the signature information and the target signature information to obtain a comparison result, which is used to determine the security of payment processing for the target business type. A sending unit is used to send the comparison result to the electronic device.

10. An electronic device comprising a processor, a memory, and a computer program or instructions stored in the memory, characterized in that, The processor executes the computer program or instructions to implement the steps of the method according to any one of claims 1-4.

11. A server, comprising a processor, a memory, and a computer program or instructions stored in the memory, characterized in that, The processor executes the computer program or instructions to implement the steps of the method according to any one of claims 5-7.

12. A computer-readable storage medium, characterized in that, It stores a computer program or instructions that, when executed, implement the steps of the method according to any one of claims 1-4 or 5-7.

Images