Payment processing method and electronic device

Abstract

The application provides a payment processing method and an electronic device. The payment processing method is applied to an electronic device, the electronic device comprises a payment middleware, the payment middleware comprises function interfaces of different payment services, the payment middleware is configured on an adaptation layer between a payment APP and a framework of the electronic device, and the method comprises the following steps: obtaining a transaction starting instruction through the payment APP, starting a corresponding transaction process after receiving the transaction starting instruction; calling the payment middleware to match a target payment processing configuration corresponding to the transaction process; executing the transaction process according to the target payment processing configuration, obtaining a target service processing result, and returning the target service processing result to the payment APP. The application realizes unified processing of payment services of different payment applications of different collecting institutions, and can reduce the development cost of payment applications.

Description

Technical Field

[0001] This invention relates to the field of payment technology, and in particular to a payment processing method and electronic device. Background Technology

[0002] Currently, there are a large number of banks and acquiring institutions worldwide, and the acceptance procedures for different banks and acquiring institutions are different. They have different functional components. Therefore, in related technologies, payment terminals such as POS machines (Point of Sale) need to develop and design multiple sets of components to adapt to various banks and acquiring institutions for payment. This is time-consuming, labor-intensive, inefficient, and not secure enough. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a payment processing method and electronic device that realizes unified processing of payment business for acquiring applications of different acquiring institutions.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A payment processing method is applied to an electronic device, the electronic device including a payment middleware, the payment middleware including functional interfaces for different payment services, the payment middleware being configured on an adaptation layer between a payment app and a framework of the electronic device, the method comprising: The transaction initiation instruction is obtained through the payment APP, and the corresponding transaction process is started upon receiving the transaction initiation instruction; The payment middleware is invoked to match the target payment processing configuration corresponding to the transaction process. The transaction process is executed according to the target payment processing configuration to obtain the target business processing result, and the target business processing result is sent back to the payment APP.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes: a payment middleware configured on an adaptation layer between a payment app and a framework of the electronic device, the payment middleware including functional interfaces for different payment services; a memory configured to store an executable program; and a processor configured to execute the program to perform the payment processing method.

[0006] The beneficial effects of this invention are as follows: By configuring a payment middleware on an electronic device, the payment middleware includes functional interfaces for different payment services. The payment middleware, integrating multiple payment service functional interfaces, is deployed in an independent adaptation layer between the payment app and the system framework. After the payment app obtains a transaction initiation command, it starts the corresponding transaction process, calls the payment middleware to match the target payment processing configuration corresponding to the transaction process, controls the underlying transaction execution logic through the target payment processing configuration, and returns the business results. This eliminates the need for payment apps developed by various acquiring institutions to repeatedly develop the same underlying code for card reading, security encryption, card organization message specifications, and terminal risk control. They only need to call the unified functional interface of the middleware to complete various payment services, significantly reducing the repetitive development and testing costs of multiple institutions and multiple POS terminal models. Therefore, the solution of this application, by deploying the payment middleware in an independent adaptation layer between the payment app and the system framework, can be understood as treating the payment middleware as a part of the transaction process of the payment application, participating in the transaction flow. Using the method of this application, the POS machine (Point of...) When payment terminals such as point-of-sale (POS) are adapted to various banks and acquiring institutions for payment processing, there is no need to develop and design multiple sets of components, which saves time and effort, is highly efficient, and the core transaction process can be carried out through transaction middleware, ensuring security. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a payment processing method provided in an embodiment of the present invention; Figure 2 A system architecture diagram of a payment processing system provided in an embodiment of the present invention; Figure 3 A system architecture comparison diagram of a payment processing system provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of an interface call for a payment processing system provided in an embodiment of the present invention; Figure 5 This is another step flowchart of a payment processing method provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0009] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0010] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0011] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0012] Currently, there are numerous bank brands worldwide, and virtually every brand has its own card acceptance terminal (such as a POS machine). The card acceptance program on these POS machines is customized to the characteristics of each bank's brand, and even different departments within the same brand may have their own custom designs. These designs include UI (User Interface) / UX (User Experience) and POS machine functional components. POS machine functional components refer to software functional components such as EMV (a globally accepted technical standard used to regulate the interaction process, security authentication, and data exchange between chip cards and payment terminals), PINPAD (Personal Identification Number Pad), magnetic stripe cards, contact IC cards, contactless IC cards, and TAG (a type of data tag) processing from different card organizations. In this situation, different bank brands need to develop different functional components. These components have incompatible interfaces, security and compliance cannot be guaranteed, and significant development resources are wasted.

[0013] For example, the payment market has many acquiring institutions, such as Getnet, Cielo, Stone, and PagBank. If each acquiring institution has its own PINPAD protocol, the following problems will arise: Poor component universality: The PINPAD protocols, EMV processing logic, and transaction field specifications of different acquiring institutions are independent, and the interfaces are not universal. Terminal manufacturers need to repeatedly develop a large number of identical functional modules, resulting in high development costs and long development cycles; Hardware resources cannot be shared: A single POS terminal needs to be adapted to multiple SDKs (Software Development Kits), and merchants often need to purchase multiple terminals to match the business of different acquiring institutions, resulting in low equipment utilization; Inconsistent security and compliance standards: Each institution implements its own encryption, key management, and card authentication logic, resulting in inconsistent technology and making it easy for compliance vulnerabilities and security risks to occur; Difficult iteration and upgrades: Different institutions have independent protocol versions, and subsequent terminal function upgrades and vulnerability fixes require one-by-one integration and adaptation, resulting in extremely high operation and maintenance costs.

[0014] To address the aforementioned problems, this application provides a payment processing method and an electronic device. The payment processing method described in detail below is an example of this application.

[0015] The payment processing method in this application can be used in electronic devices, which include payment middleware. The payment middleware includes functional interfaces for different payment services and is configured on an adaptation layer between the payment app and the framework of the electronic device. The electronic device in this application can be an electronic device capable of various financial transactions, such as various forms of bank card acceptance terminals (e.g., POS machines). The electronic device can contain multiple hardware modules (e.g., PINpad keypads, contact / contactless card readers, printing modules, etc.) or can connect to multiple peripheral devices, such as barcode scanners. It also supports the installation of payment apps from different acquiring institutions.

[0016] A payment app (application) includes acquiring institution applications on electronic devices, such as bank-customized acquiring software, and payment applications from institutions like Getnet, Cielo, and Stone. This payment app provides a UI interface to merchants or cashiers, initiating transaction instructions, but it does not directly handle the underlying card logic and encryption. Instead, it completes the payment by calling the interface of the payment middleware.

[0017] The framework includes the application framework layer at the operating system level, such as the Android Framework, which sits between the application layer and the system runtime layer. The application layer includes system applications (APPs) and third-party applications (APPs). The system runtime layer includes native libraries, the ART (Android Runtime) virtual machine, etc., and is used to communicate with the Hardware Abstraction Layer (HAL) through its interface.

[0018] The payment middleware in this application resides in the adaptation layer, which is the logical hierarchical position of the payment middleware in the system architecture, situated between the payment app and the framework. The role of this layer is to shield the differences between the upper and lower layers, providing a unified API (Application Programming Interface) to the upper layers and adapting to the hardware drivers and system versions of different terminal manufacturers, thereby achieving cross-device and cross-institutional compatibility. For example, the payment middleware provides a unified interface and standard, encapsulating functions such as payment transactions, card processing, encryption, and secure communication, thus avoiding redundant development for each payment terminal or manufacturer and achieving code reuse. The payment middleware also ensures that different devices or applications comply with the industry standards stipulated by ABECS (a unified industry standard for the payment industry). The payment middleware provides the following functions: a PINPAD module for initializing the PINPAD, customizing its color, layout, and appearance, and PIN input; a contactless card module for card finding, activation, authentication, reading, writing, obtaining card information, and resetting; an EMV module for setting the AID, CA public key, and transaction risk parameters; a printing module for setting fonts, printing text, printing QR codes, and printing images; an encryption module for obtaining the KSN, injecting working keys, and encrypting data; and other modules for updating, installing, uninstalling, and setting time zones.

[0019] The payment processing method of this invention is described in detail below, with reference to the appendix. Figure 1 This includes steps 110-140.

[0020] Step 110: Obtain the transaction start instruction through the payment APP, and start the corresponding transaction process after receiving the transaction start instruction.

[0021] In some embodiments of this application, a user can initiate a payment operation through a payment app. The payment app, in response to the user's payment operation, generates a transaction initiation command. This transaction initiation command can be a card swipe transaction command, a QR code scan transaction command, a refund transaction command, or other types of payment transaction commands. After obtaining the transaction initiation command, the payment app initiates the corresponding transaction process. The transaction process includes a complete workflow from transaction initiation to transaction completion, including card data reading, transaction data assembly, encryption processing, message sending, and response reception.

[0022] Step 120: Invoke the payment middleware to match the target payment processing configuration corresponding to the transaction process.

[0023] In some embodiments of this application, after obtaining the transaction initiation command, the corresponding interface of the payment middleware is called to match the corresponding target payment processing configuration based on the transaction process type and related information. The payment processing configuration includes a set of various parameters and rules required to execute a specific transaction process, including transaction field specifications and key configurations. After obtaining a consumer-type transaction initiation command, the configuration matching interface of the payment middleware is called to automatically retrieve and match the corresponding target payment processing configuration based on information such as the current transaction process type (contact IC card consumption), the associated acquiring institution identifier (PagBank), and the device model. The target payment processing configuration includes the parameters and execution rules required for this transaction, such as transaction field filling specifications and key partitioning configurations. Subsequent processing, including card interaction, message assembly, and encryption operations, is performed according to the target payment processing configuration.

[0024] Step 130: Execute the transaction process according to the target payment processing configuration, obtain the target business processing result, and send the target business processing result back to the payment APP.

[0025] In some embodiments of this application, according to the target payment processing configuration matched in step S120, various processing operations in the transaction process are executed. These processing operations include transaction data acquisition, message conversion, encrypted communication, etc., and finally, the business processing result is obtained and returned to the payment APP.

[0026] As described above, by configuring payment middleware on electronic devices, including functional interfaces for different payment services, and deploying the payment middleware in the adaptation layer between the payment app and the framework, and utilizing its unified functional interfaces, standardized payment processing capabilities are provided to upper-layer applications. This allows the payment app to initiate complex payment transactions and start the corresponding transaction process simply by calling the payment middleware to match the target payment processing configuration corresponding to the transaction process. The target payment processing configuration controls the underlying transaction execution logic and returns the business results. This eliminates the need for payment apps developed by various acquiring institutions to repeatedly develop the same underlying code for card reading, security encryption, card organization message specifications, and terminal risk control. They only need to call the unified functional interfaces of the middleware to complete various payment transactions, significantly reducing the cost of repetitive development and testing for multiple institutions and POS terminals of different models. Therefore, the solution in this application, by deploying the payment middleware in an independent adaptation layer between the payment app and the system framework, can be understood as treating the payment middleware as a part of the transaction process of the payment application, participating in the transaction flow. Using the method of this application, the POS machine (Point of POS) can... When payment terminals such as ofSale (point of sale) are adapted to various banks and acquiring institutions for payment processing, there is no need to develop and design multiple sets of components, which saves time and effort and is highly efficient. Moreover, the core transaction process can be carried out through the transaction middleware. The application does not directly handle cards or encryption, but calls the payment middleware to process card data, thereby improving the security of payment processing.

[0027] In some embodiments of this application, step 120, which calls the payment middleware to match the target payment processing configuration corresponding to the transaction process, includes steps 121 to 122.

[0028] Step 121: Obtain the card data corresponding to the transaction initiation instruction.

[0029] In some embodiments of this application, the payment app calls the card processing interface of the payment middleware, sends the transaction initiation command to the hardware abstraction layer (HAL) through the card processing interface, and the HAL drives the card reader hardware to perform the card reading operation. Then, the app receives the card data returned by the HAL after executing the transaction initiation command. Card data includes raw data read from the bank card. For example, for contact and contactless chip cards, the card reading command is sent down level by level through the card processing interface, and the card data returned by the hardware layer includes the Application Identifier (AID). For magnetic stripe cards, card data includes the primary account number, expiration date, service code, checksum, etc. The AID (Application Identifier) ​​is used to identify a specific application on the card. For example, a card supporting VISA has a VISA AID, a card supporting Mastercard has a Mastercard AID, a card supporting UnionPay has a UnionPay AID, and a card supporting both VISA and UnionPay has both VISA and UnionPay AIDs.

[0030] Step 122: Call the payment middleware to match the target payment processing configuration based on the card data, and obtain the target payment processing configuration corresponding to the transaction process.

[0031] In some embodiments of this application, after receiving card data, the target card organization to which the card belongs (such as VISA, Mastercard, UnionPay, JCB, American Express, etc.) is first identified based on the card data, and then the corresponding payment processing configuration is matched according to the card organization type.

[0032] As described above, the payment middleware obtains the original card data output by the card reader, and then automatically matches and adapts the transaction field specifications, key parameters, EMV interaction rules and other payment processing configurations to the current transaction based on the inherent information of the card organization and card type. This eliminates the need for the payment APP to identify the card organization, distinguish the card type and maintain multiple sets of configuration files, reducing the amount of repetitive card information identification and configuration adaptation code. It enables multiple acquiring institutions to share the same card identification and configuration matching mechanism, thereby reducing the development and testing workload of multiple institution terminals.

[0033] In some embodiments of this application, step 121 obtains the card data corresponding to the transaction initiation instruction, including steps 1211 to 1212.

[0034] Step 1211: Call the card processing interface of the payment middleware, and send the transaction initiation command to the hardware abstraction layer through the card processing interface.

[0035] In some embodiments of this application, the card processing interface is an API category provided by the payment middleware, which is responsible for encapsulating the transaction initiation instruction into a hardware operation instruction and sending it to the hardware abstraction layer. This interface shields the driver differences of different card reader models and unifies the calling methods of card search, card selection, and card reading.

[0036] Step 1212: Receive the card data returned by the hardware abstraction layer after executing the transaction initiation instruction.

[0037] In some embodiments of this application, the raw card data returned by the hardware abstraction layer after successfully executing the transaction initiation instruction is continuously monitored and received, thereby sending the reading results of the underlying hardware back to the middleware layer.

[0038] As described above, by encapsulating standardized card processing interfaces through payment middleware to relay card reading instructions and receive card data returned by the hardware abstraction layer, the payment APP is completely isolated from the underlying hardware driver. Various acquiring payment APPs at the upper layer do not need to adapt to the private communication protocols and read / write hardware instructions of different manufacturers' hardware abstraction layers, nor do they need to develop separate card reader driver interaction code. All hardware interaction logic is uniformly handled by the middleware, eliminating a large amount of repetitive adaptation and development work caused by the differences in hardware interfaces of multiple brands and models of POS terminals.

[0039] In some embodiments of this application, step 122 calls the payment middleware to match the target payment processing configuration according to the card data to obtain the target payment processing configuration corresponding to the transaction process, including steps 1221 to 1223.

[0040] Step 1221: Based on the target card organization in the card data, call the transaction field parsing interface of the payment middleware to obtain the target transaction field specification adapted to the target card organization.

[0041] In some embodiments of this application, different card organizations have different requirements for the field formats of transaction messages. The transaction field specifications of major card organizations are pre-stored within the payment middleware, including mapping rules for ISO 8583 standard fields and specifications for EMV-related core fields. Field specifications include filling in various information in a specified format, such as transaction amount (F4), transaction time (F7 / F12 / F13), merchant number (F42), terminal number (F41), MCC (F18), STAN (F11), RRN (F37), response code (F39), and other fields, as well as 9F02 (authorized amount), 9F03 (other amounts), 9F1A (terminal country code), 5F2A (transaction currency), 9F06 (card application identifier), 9F33 (terminal supported verification methods), 9F34 (cardholder verification result), and 9F35 (terminal type). Based on the identified target card organization, the corresponding field specifications are obtained from the transaction field parsing interface.

[0042] Step 1222: Based on the target card organization, call the key management interface of the payment middleware to obtain the target key configuration adapted to the target card organization.

[0043] In some embodiments of this application, key mapping relationships for different businesses and different acquirers are stored internally within the payment middleware. The key management interface manages multiple Key Application Areas (KAPs), each containing multiple key indices (KEY IDs). Based on the card organization information and transaction process type in the card data, the corresponding KAP and KEY ID are selected through the key management interface as the target key configuration.

[0044] Step 1223: Configure the target transaction field specification and target key configuration as the target payment processing configuration corresponding to the transaction process.

[0045] In some embodiments of this application, the matched transaction field specifications and key configurations are combined into a target payment processing configuration for subsequent transaction data processing and message generation. For example, when the current transaction process is a UnionPay contactless chip card transaction, a target transaction field specification adapted to the UnionPay specification and a target key configuration of UnionPay are matched.

[0046] As described above, the payment middleware, based on the target card organization in the card data, calls the standardized transaction field parsing interface and key management interface respectively, automatically matches the transaction field specifications and key configuration of the corresponding card organization and integrates them into the target payment processing configuration, thereby achieving unified adaptation of field specifications and key systems.

[0047] In some embodiments of this application, step 130 executes the transaction process according to the target payment processing configuration, obtains the target business processing result, and sends the target business processing result back to the payment APP, including steps 131 to 133.

[0048] Step 131: Obtain the transaction data from the transaction initiation instruction based on the card type in the card data.

[0049] In some embodiments of this application, transaction data is obtained in different ways depending on the card type identified in the card data. The card type includes chip cards or magnetic stripe cards.

[0050] Step 132: Convert the transaction data into a transaction message according to the target payment processing configuration.

[0051] In some embodiments of this application, the transaction message is a data packet encapsulated according to the target card organization's specifications (such as ISO 8583) for network transmission. Based on the target transaction field specifications in the target payment processing configuration, the acquired transaction data is standardized, repackaged, and format-converted. According to the target key configuration, the corresponding encryption interface is called to securely encrypt sensitive fields such as the PIN (Personal Identification Number) and magnetic stripe information in the message, ultimately generating a secure transaction message conforming to the card organization's specifications.

[0052] Step 133: Call the communication interface of the payment middleware to send the transaction message to the acquiring institution corresponding to the card data, and receive the response message returned by the acquiring institution.

[0053] In some embodiments of this application, the system calls its own communication interface to send the transaction message to the acquiring institution mapped by the card data. After successfully receiving the response message containing key information such as the authorization code and response code returned by the acquiring institution, the system sends it back to the middleware layer.

[0054] As described above, the entire process of transaction execution and message interaction is completed according to the target payment processing configuration. The payment middleware collects transaction data in a differentiated manner according to different card types such as magnetic stripe cards and chip cards. Then, it combines the matched card organization field specifications and key configuration to standardize and package the transaction data to generate transaction messages. Finally, it completes the message sending and receiving interaction with the acquiring institution through a unified communication interface. The underlying logic of card data parsing, message formatting, and institutional communication is all implemented internally by the middleware. The upper-layer payment APP does not need to develop data extraction, message encapsulation, and network communication code separately for various types of cards and acquiring institutions, thereby avoiding the duplication of development of multiple sets of business logic.

[0055] In some embodiments of this application, step 131 obtains the transaction data in the transaction initiation instruction based on the card type in the card data, including steps 1311 to 1316.

[0056] Step 1311: When the card type is a chip card, call the card activation interface of the payment middleware to activate the chip card, and obtain the application identifier of the chip card after activation.

[0057] In some embodiments of this application, for contact chip cards, the card activation interface controls the hardware to power on and reset the card; for contactless chip cards, the contactless card module performs card finding and activation. After successful activation, the application identifier returned by the card is obtained.

[0058] Step 1312: Select the target card application in the chip card based on the application identifier.

[0059] In some embodiments of this application, if the card supports multiple applications, such as simultaneously supporting VISA and UnionPay, a target card application is selected from the card data according to a preset application priority or user selection.

[0060] Step 1313: Call the card reading interface of the payment middleware to read the application data of the target card application.

[0061] In some embodiments of this application, necessary application data, including cardholder information, account information, application transaction counters, etc., are read from a selected card application through a card reading interface.

[0062] Step 1314: Call the card authentication interface of the payment middleware to perform cardholder verification based on the application data.

[0063] In some embodiments of this application, cardholder verification is performed based on the cardholder verification method and restrictions in the application data. For example, when performing PIN verification, the PINPAD module is called to initialize the PINPAD, such as defining its appearance (color, layout, etc.) during initialization, guiding the cardholder to enter their PIN, and obtaining the cardholder verification result. A pre-stored root public key (CAPK, Certification Authority Public Key) is also used to authenticate the card data and verify its authenticity. The CAPK is the starting point of the EMV trust chain, and the POS terminal uses the CAPK to verify whether the card is counterfeit.

[0064] Step 1315: Call the risk management interface of the payment middleware to perform terminal risk verification based on the terminal risk parameters in the target payment processing configuration.

[0065] In some embodiments of this application, terminal risk management verification is performed based on terminal risk parameters in the target payment processing configuration, including offline transaction amount thresholds, consecutive offline transaction limit, etc., to determine whether the current transaction is allowed to be processed offline or must be processed online.

[0066] Step 1316: After the cardholder verification and terminal risk verification are both passed, construct the first transaction data based on the application data and the business data in the transaction initiation instruction, and use the first transaction data as the transaction data in the transaction initiation instruction.

[0067] In some embodiments of this application, after the cardholder verification and terminal risk verification are both passed, the read application data and the business data in the transaction initiation instruction are used to construct the first transaction data.

[0068] As described above, for chip cards, the standardized EMV processing flow is executed by the standardized interfaces of the payment middleware. The business logic such as chip card activation, AID application screening, card data reading, cardholder CVM verification, terminal risk control verification, and transaction data assembly is uniformly encapsulated within the middleware. The upper-layer payment APP does not need to develop its own EMV interaction logic, saving the development cost of each acquiring institution repeatedly writing the underlying interaction code for chip cards. The entire process strictly follows the unified EMV specifications of each card organization. Different acquiring institutions and different terminals use completely consistent card processing, verification, and risk control rules when executing chip card transactions, thereby ensuring the security of chip payment.

[0069] In some embodiments of this application, step 131, which obtains the transaction data in the transaction initiation instruction based on the card type in the card data, also includes steps 1317 to 1319.

[0070] Step 1317: When the card type in the target card information is a magnetic stripe card, call the magnetic stripe card verification interface of the payment middleware to perform data integrity verification on the obtained card data.

[0071] In some embodiments of this application, when the current card type is identified as a magnetic stripe card, the magnetic stripe card verification interface is first called to perform data integrity verification on the original card data returned by the hardware abstraction layer. For example, the integrity and authenticity of the magnetic stripe data are usually verified by the LRC (Longitudinal Redundancy Check) verification algorithm to ensure that the read magnetic stripe information has not been tampered with or has errors.

[0072] Step 1318: After the data integrity verification is passed, extract the main account number, card validity period, service code and verification value of the magnetic stripe card from the card data.

[0073] In some embodiments of this application, after verification, fields such as the main account number, card validity period, service code, and card verification value (CVV) of the magnetic stripe card are extracted from the verified magnetic stripe data.

[0074] Step 1319: Construct second transaction data based on the main account, card validity period, service code, verification value, and business data in the transaction initiation instruction, and use the second transaction data as the transaction data in the transaction initiation instruction.

[0075] In some embodiments of this application, the extracted card information and business data are combined to construct second transaction data.

[0076] As described above, for magnetic stripe cards, the payment middleware integrates all the logic for magnetic stripe data integrity verification, core card information extraction, and transaction data integration and construction within the payment middleware for unified implementation. Various acquiring and payment apps at the upper layer do not need to develop separate code for magnetic stripe card data verification and field parsing, thus avoiding the duplication of development of the same underlying logic by multiple acquiring institutions, thereby reducing the workload of development and testing.

[0077] In some embodiments of this application, the payment processing method further includes steps 140 to 160.

[0078] Step 140: Obtain the transaction data from the transaction initiation instruction based on the card type in the card data.

[0079] In some embodiments of this application, after the target payment processing configuration is matched, based on the card type in the card data, the complete EMV process is executed from the chip card or the magnetic stripe card is verified and key information is extracted by calling the corresponding card processing interface, thereby obtaining the complete transaction data required for the current transaction. Card types include chip cards and magnetic stripe cards. The EMV process includes activation, application selection, data reading, cardholder verification, and risk management.

[0080] For example, card authentication in the EMV process includes the following steps: inserting the card; powering on the card and initializing it; initializing the response; obtaining the card AID; and selecting the card application by priority or user.

[0081] Step 150: Reassemble the transaction data according to the target transaction field specification to obtain the initial transaction message.

[0082] In some embodiments of this application, transaction data is repackaged according to the target transaction field specifications in the target payment processing configuration to obtain an initial transaction message conforming to the target card organization specifications. Each information item in the transaction data is filled into the corresponding field position according to the specified format of the target transaction field specifications. For example, the transaction amount is filled into field F4, the transaction time into fields F7 / F12 / F13, the merchant number into field F42, the terminal number into field F41, the MCC into field F18, and the STAN into field F11, etc.; for EMV-related data, the authorized amount is filled into field 9F02, the terminal country code into field 9F1A, and the transaction currency into field 5F2A, etc.

[0083] Step 160: Based on the target key configuration, call the encryption interface of the payment middleware to encrypt the initial transaction message and obtain the encrypted transaction message.

[0084] In some embodiments of this application, the initial transaction message needs to be encrypted according to the target key configuration. Encryption processing includes operations such as PIN encryption, MAC calculation, and data encryption.

[0085] As described above, by obtaining transaction data through card type, reassembling the packet according to the target transaction field specifications, and encrypting it by calling the encryption interface according to the target key configuration, the original card data and business data, after being standardized by the middleware, directly generate a final transaction message that conforms to the corresponding card organization specifications and is securely encrypted. By uniformly converting transaction data into a message format that meets the requirements of the target card organization through field specifications, the differences in message structure between different card organizations are completely masked. The initial message is securely hardened through key configuration, ensuring the confidentiality and integrity of sensitive data during transmission.

[0086] In some embodiments of this application, step 160 involves calling the encryption interface of the payment middleware to encrypt the initial transaction message according to the target key configuration, thereby obtaining the encrypted transaction message, including steps 161 to 162.

[0087] Step 161: Based on the target key configuration, determine the target key application partition and target key index corresponding to the transaction initiation instruction.

[0088] In some embodiments of this application, the corresponding KAP (Key Application Partition) area and KEY ID are selected from the target key configuration based on the business type and acquirer information of the transaction process. One KAP area contains multiple KEY IDs. Different KAP areas are used to support key sharing for different businesses or different acquirers, and different KEY IDs are used to distinguish between different businesses or different acquirers, preventing cross-use of keys. When injecting keys, various keys are injected according to a preset mapping relationship (e.g., KEY ID 0000 corresponds to PagBank, KEY ID 0001 corresponds to Stone).

[0089] Step 162: Based on the target key application partition and target key index, call the encryption interface corresponding to the initial transaction message to encrypt the initial transaction message, and obtain the encrypted transaction message.

[0090] For example, encryption functions mainly include PIN encryption, MAC calculation, data encryption, and key selection. The encryption execution process includes: obtaining encrypted data, such as obtaining a PIN or the data to be encrypted; selecting the key area (KAP); selecting the key index (KEY ID); calling the corresponding interface for encryption (e.g., the interfaces for PIN, MAC, and magnetic stripe encryption are different); and returning the encryption result.

[0091] The management of encrypted keys includes: allocating key areas (KAPs) to support key sharing among different services or acquiring parties; each KAP contains multiple KEY IDs; assigning KEY IDs to different services or acquiring parties to prevent cross-use of keys; injecting keys according to mapping relationships, for example, KEY ID 0000 corresponds to PagBank; KEY ID 0001 corresponds to Stone; injecting various keys; and supporting remote key updates through secure channels.

[0092] As described above, by first determining the target key application partition and target key index corresponding to the current transaction based on the target key configuration before encryption processing, and then calling the corresponding encryption interface to perform encryption based on the partition and index, logical isolation at the key level is achieved for different business types or different acquiring parties, ensuring that the keys of each party do not interfere with each other. When it is necessary to add an acquiring party or adjust the key mapping relationship, only the configuration needs to be updated without modifying the encryption execution code, thereby improving the scalability and key management efficiency of the system.

[0093] In some embodiments of this application, the payment processing method includes the following steps: During the transaction initiation phase, the POS payment application (APP) initiates the specific transaction (such as swiping a card, scanning a code, or refunding), generating a transaction initiation command; this corresponds to step 110. The application does not directly handle card reading or data encryption, but instead calls the unified function interface of the payment middleware, which then takes over the subsequent card data processing; corresponding to steps 120, 121, 1211, 1212, 122, 1221, 1222 and 1223. In the EMV process and security phase, the payment middleware independently completes the entire card authentication, key management, and encryption operations, ultimately generating a secure transaction message that conforms to the card organization's specifications and returning the processing result. This corresponds to steps 130, 131, 1311 to 1319, 132, 133, 140, 150, 160, 161, and 162.

[0094] Figure 2 This diagram illustrates the architecture of a payment processing system according to an embodiment of the present invention. The payment processing system is used to implement a payment processing method. (Refer to...) Figure 2 The system consists of a three-layer architecture from top to bottom: the payment application layer, the payment middleware layer, and the HAL (Hardware Abstraction Layer) hardware adaptation layer. The three layers interact with each other through standardized interfaces.

[0095] The payment application layer (top layer) includes various business payment applications, adapting to scenarios from different POS equipment manufacturers, different models of smart POS terminals, and acquiring apps developed by different overseas acquiring institutions (PagBank, Stone, Cielo, Getnet, etc.). All payment applications no longer directly handle the underlying card reading, encryption, and chip interaction logic. They only use a unified standard bidirectional interface to complete the issuance of transaction instructions and the receipt of transaction results with the lower-layer payment middleware. Upper-layer applications do not need to be aware of the differences in underlying hardware, card protocols, and encryption implementations.

[0096] The payment middleware layer, as an independent adaptation layer, is provided to all payment applications for integration in the form of a static library. It encapsulates three core capability modules: the EMV transaction process module, the security and encryption module, and the tools and general function module.

[0097] For example, the payment middleware provides a unified interface and standard. The payment middleware is integrated into the codebase of each acquiring application as a static library, uniformly encapsulating the underlying capabilities of the entire payment transaction, card processing, data encryption, and secure communication chain, and outputting standardized calling interfaces. Based on unified card operation and encryption, it achieves high code reusability, completely avoiding the duplication of development of similar underlying functions by various terminal manufacturers and acquiring institutions. At the same time, it mandates that all devices and upper-layer applications connected to the payment middleware uniformly comply with the industry technical specifications published by ABECS.

[0098] The payment middleware supports EMV and bank card processing. It supports processing flows for magnetic stripe cards, contact IC cards, and contactless payments. For example, it implements the EMV process, including card activation and application selection, application initialization, application data reading, cardholder CVM verification, terminal risk management, and online interaction between the terminal and the issuing bank. The middleware has built-in unified management capabilities for AID application identifiers and CAPK certificate root public keys. Furthermore, the payment middleware supports secure communication between the terminal and the acquiring institution by storing a MKSK-mode master key and a DUKPT-mode BDK base key in a local shared library. These two encryption modes are used for encrypting and securely transmitting transaction data between the terminal and the acquiring institution.

[0099] Payment middleware simplifies development and authentication processes. Payment terminal and acquiring application developers can directly utilize the middleware's built-in modular capabilities, such as the PINPAD module for initializing the PINPAD, customizing its color, layout, and appearance, and PIN input; the contactless card module for card finding, activation, authentication, reading, writing, obtaining card information, and resetting; the EMV module for setting the AID, CA public key, and transaction risk parameters; the printing module for setting fonts, printing text, printing QR codes, and printing images; the encryption module for obtaining the KSN, injecting working keys, and data encryption; and other modules for updating, installing, uninstalling, and setting time zones.

[0100] Payment middleware essentially transforms the error-prone, complex, and repetitive payment logic into a unified module, thereby reducing redundant development and misunderstandings among different individuals, lowering the error rate and shortening the testing cycle.

[0101] The payment middleware provides interfaces and related interface descriptions. Certification authorities only need to integrate the payment middleware into their acquiring applications and execute programs according to the interface descriptions to verify whether the middleware's interface behavior meets expectations. For certification authorities, this also allows for standardized verification of the payment middleware's behavior, thereby simplifying the certification process.

[0102] The payment middleware deeply integrates security modules, such as PIN encryption, key management, and transaction message encryption. The overall design fully complies with the major global card organizations and local payment security standards, thereby avoiding the risks associated with each vendor implementing its own security modules.

[0103] The EMV transaction process module is configured to uniformly implement standardized interaction logic for all card types, including card authenticity authentication for contact IC cards and contactless IC cards; unified management of CAPK root public key and card AID application identifier parameters; and complete encapsulation of standardized consumption, pre-authorization, refund and other full-category EMV transaction process management logic, with all acquiring institutions sharing the same set of card interaction rules.

[0104] The security and encryption module is configured with a built-in isolated key management mechanism to uniformly manage the MKSK (Master Key) and DUKPT (Derived Unique Key Per Transaction) session keys, and to achieve key isolation for multiple acquiring institutions through KAP partitioning and KEY ID; it also features standardized encapsulation of PIN code encryption, transaction-sensitive message data encryption, and MAC verification calculation capabilities, uniformly meeting the payment security compliance requirements of global card organizations.

[0105] The tools and general function modules are configured to provide unified logging and transaction report generation capabilities throughout the entire process; they have built-in standardized transaction anomaly capture, anomaly recovery, and anomaly return code handling logic, so that each acquiring institution does not need to develop separate logging and anomaly branch code.

[0106] The payment middleware outputs a unified business API to payment applications and connects to the underlying hardware layer, enabling a single middleware to be compatible with all types of terminals and acquiring institutions.

[0107] HAL Hardware Adapter Layer (bottom layer) is a native hardware abstraction adapter layer for POS manufacturers, which encapsulates private drivers for hardware devices such as card readers, PINPADs, printers, and encryption chips, and outputs the manufacturer's private SDK / API protocols to the outside world.

[0108] The payment middleware interfaces with the HAL layer through vendor-specific protocols. The middleware internally handles compatibility and adaptation with different vendors' proprietary hardware protocols, so the upper-layer payment application is completely unaware of the hardware differences and does not need to redevelop hardware interaction logic for different POS vendors.

[0109] Figure 3 This is a system architecture comparison diagram of a payment processing system provided in an embodiment of the present invention. Specifically, it is a schematic diagram comparing the POS payment architecture in related technologies with the system architecture of the present invention after adopting payment middleware. The left side of the attached figure shows the traditional docking mode of the prior art, and the right side shows the unified docking mode of the payment middleware improved by the present invention.

[0110] In the traditional architecture, the POS terminal directly interacts bidirectionally with the underlying financial modules such as PINPAD, encryption, and card processing. The entire set of financial module logic can only be adapted to and connected to a single acquiring institution.

[0111] This invention adds a payment middleware as a unified transit adaptation layer between the POS terminal and the underlying PINPAD, encryption, and card-based financial modules, forming a three-layer interaction link: POS terminal - payment middleware - PINPAD / encryption / card-based financial module. The payment middleware is compatible with multiple acquiring institutions and can simultaneously connect to multiple different acquiring institutions such as Acquirer1, Acquirer2, and Acquirer3; all payment transaction requests from acquiring institutions are uniformly dispatched to the underlying financial modules through the payment middleware.

[0112] Figure 4 This is a schematic diagram of an interface call for a payment processing system provided in an embodiment of the present invention. (Refer to...) Figure 4The overall architecture, from top to bottom, consists of a payment application, payment middleware, HAL hardware adaptation layer, and hardware devices. Each layer uses standardized interfaces to complete bidirectional data interaction. The overall framework also includes a framework layer and a system runtime layer. The framework layer communicates with the system runtime layer by calling JNI (Java Native Interface, a set of programming interface specifications used to enable cross-language communication between the upper Java framework layer code and the lower system runtime layer C / C++ native code). The system runtime layer communicates with the hardware abstraction layer (HAL) through its interface.

[0113] The payment application and the payment middleware communicate bidirectionally through a standardized API interface. Payment applications developed by various acquiring institutions only call the unified business API exposed by the payment middleware, without needing to be aware of the underlying hardware interaction logic. The payment middleware is used to implement steps 120, 121-122, 1211-1212, 1221-1223, 130, 131-133, 1311-1319, 140, 150, 160, and 161-162.

[0114] The payment middleware includes a standardized, shared payment function library to simplify payment terminal development, ensure EMV processes and security compliance, and support authentication processes. The payment middleware integrates transactions from multiple major card organizations such as VISA, MASTERCARD, JCB, UPI, American Express, Discover, and Diners Club, thus supporting their authentication processes. The payment middleware communicates with the underlying HAL hardware adaptation layer via an AIDL interface for command and data transmission. AIDL enables cross-layer inter-process communication, shielding the differences in proprietary protocols of different POS vendors' HAL layers.

[0115] The HAL hardware adapter layer directly interfaces with the underlying hardware devices to complete the driver control of physical hardware such as card readers, PINPADs, encryption chips, and printing modules.

[0116] This application enables payment applications to interact with middleware solely through a unified API. The middleware connects to the hardware abstraction layer via AIDL (Android Interface Definition Language), thereby decoupling payment services from hardware devices. A single payment middleware can be adapted to POS terminals from different manufacturers and with different hardware configurations.

[0117] Figure 5This is a flowchart illustrating another step of a payment processing method provided in an embodiment of the present invention. This embodiment provides a payment middleware implementation method applied to a POS terminal device. The POS terminal is a smart POS machine, equipped with applications from multiple acquiring institutions, such as Getnet. Payment apps include Cielo, PagBank, and Stone. Both apps integrate payment middleware, for example, by linking it to the project code as a static library. (See reference...) Figure 5 This includes steps 201 to 209.

[0118] Step 201: Initialize deployment and key mapping configuration.

[0119] In some embodiments of this application, an initialization configuration is performed when the POS terminal is shipped or used for the first time. The initialization configuration includes establishing a mapping relationship between the acquiring institution and the key application partition and key index. For example, PagBank's MKSK master key is injected into the storage area corresponding to key application partition A and key index 0000, and Stone's MKSK master key is injected into the storage area corresponding to key application partition B and key index 0001, achieving physical isolation of keys from different acquiring institutions and preventing cross-use of keys. This corresponds to the initialization deployment and key mapping configuration steps prior to step 110.

[0120] Step 202: Transaction initiation and middleware invocation.

[0121] In some embodiments of this application, when a cardholder selects the PagBank acquiring app for payment on a POS terminal, the PagBank app's UI layer displays the transaction amount. After the cashier or cardholder confirms the transaction, the PagBank app does not directly process the card hardware or execute encryption logic. Instead, it calls the business API interface provided by the payment middleware to pass basic information such as the transaction amount and currency to the payment middleware. This corresponds to step 110.

[0122] Step 203, Card Detection and Type Sorting.

[0123] In some embodiments of this application, upon receiving a call request, the underlying driver first detects whether a card is currently inserted or near the terminal: if a contact IC card is detected, the chip card processing flow is executed; if a contactless IC card is detected, the contactless chip card processing flow is executed; if a magnetic stripe card is detected, the magnetic stripe card processing flow is executed. For example, if a cardholder inserts a contact chip card into the POS terminal, the contact IC card is detected, and the chip card processing flow is initiated; if a cardholder inserts a magnetic stripe card into the POS terminal, the magnetic stripe card is detected, and the magnetic stripe card processing flow is initiated. These correspond to steps 120, 121, 1211, and 1212.

[0124] Step 204: Execute the card processing flow.

[0125] In some embodiments of this application, if the card is a chip card, the chip card data processing flow includes: card activation and application selection; application initialization processing; reading application data; cardholder verification; terminal risk management; and terminal-issuing bank online processing. These correspond to steps 1311 to 1316 and step 140.

[0126] If the card is a magnetic stripe card, the magnetic stripe card processing procedure is executed. This procedure includes: reading the magnetic stripe data; performing data integrity verification such as LRC; extracting the main account, expiration date, service code, and CVV value from the magnetic stripe data; filling the above data into a standard data structure according to a unified field specification; performing encryption processing and packet assembly, and returning the data to the payment app. These correspond to steps 1317 to 1319 and step 140.

[0127] Step 205: Unified encryption processing.

[0128] In some embodiments of this application, encryption operations are performed based on the current caller's identity: The call context identifies that the current transaction initiator is a PagBank acquiring app, automatically selecting the corresponding PagBank KAP zone and KEY ID; the data to be encrypted is obtained; the encryption module's encryption interface is called, such as a PIN encryption interface, MAC calculation interface, or magnetic stripe encryption interface; and the encryption result is obtained. This corresponds to steps 1222, 160, 161, and 162.

[0129] Step 206, standardize and package the fields.

[0130] In some embodiments of this application, all transaction data processed in steps 204 and 205 are filled into a standard data structure according to a unified field specification to form a transaction message. The fields in the transaction message include: transaction amount (F4); transaction time (F7): current date and time; merchant number (F42): preset merchant number; terminal number (F41): preset terminal number; MCC (F18): preset merchant category code; STAN (F11): system tracking number; RRN (F37): retrieval reference number; response code (F39): initially empty, to be filled in after online authorization; EMV core fields: 9F02, 9F03, 9F1A, 5F2A, 9F06, 9F33, 9F34, 9F35, etc., filled in according to the specification; encrypted PIN Block and MAC, etc. These correspond to steps 1221 and 150.

[0131] Step 207: Return data to the acquiring app.

[0132] In some embodiments of this application, the transaction message generated in step 206 is returned to the PagBank acquiring APP. After receiving the standard data packet, the PagBank APP encapsulates it according to PagBank's own ISO8583 message format and uploads it to the PagBank backend system for online authorization. Steps 132 and 133 are prerequisite steps.

[0133] Step 208, Transaction result processing.

[0134] In some embodiments of this application, after PagBank returns the authorization result, the PagBank APP sends the response code (F39) and other information back to the payment middleware. If a transaction voucher needs to be printed, the PagBank APP calls the printing module API of the payment middleware, passes in the print content, and masks the differences between different printer models, uniformly performing the layout and output of text and QR codes. This corresponds to step 133.

[0135] In summary, this application provides a payment processing method and electronic device, offering a unified interface and standard to reduce redundant development. The payment middleware encapsulates functions such as payment transactions, card processing, encryption, and secure communication, avoiding the need for each acquiring institution to repeatedly develop EMV processes and encryption logic, thus achieving code reuse. The payment middleware provides interfaces and related interface descriptions; certification authorities only need to integrate the payment middleware into their acquiring applications and execute the program according to the middleware's interface descriptions to verify whether the middleware's interface behavior meets expectations.

[0136] Achieve key isolation and hardware sharing. Through the KAP zone and KEY ID mapping mechanism, different acquiring institutions can use their own keys on the same POS terminal without interference, and share hardware devices such as PINPADs and contactless card readers, reducing merchants' equipment procurement costs.

[0137] Ensuring security and compliance. The payment middleware integrates a unified security module (PIN encryption, key management, transaction encryption), complying with payment security standards and avoiding the risks associated with each vendor implementing its own security module. Certification authorities only need to uniformly verify the behavior of the payment middleware, thus simplifying the certification process for each acquiring institution.

[0138] Simplify the development and certification process. Payment terminal or application developers can directly call the functional interfaces provided by the payment middleware, reducing development errors and shortening the testing cycle.

[0139] A unified EMV process ensures consistency. The payment middleware abstracts the card operations of various card organizations into a unified API interface, ensuring that all acquiring institutions using this middleware have completely consistent card interaction rules when executing consumption transactions.

[0140] Please refer to Figure 6 The present invention also provides an electronic device 600, including a memory 601 and a processor 602, and a computer program stored on the memory 601 and running on the processor 602. When the processor 602 executes the computer program, it implements the various steps of the payment processing method described above.

[0141] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0142] This application provides a payment processing method and electronic device. By providing a payment middleware—a standardized, shared library of payment functions—it simplifies payment terminal development, ensures EMV processes and security compliance, and supports authentication processes. The payment middleware integrates transactions from multiple major card organizations, including VISA, MASTERCARD, JCB, UPI, American Express, Discover, and Diners Club, thus supporting their authentication processes. The payment middleware allows different acquiring institutions to share the same middleware, and different acquiring applications to use the same payment middleware.

[0143] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A payment processing method, characterized in that, The method, applied to an electronic device including a payment middleware, wherein the payment middleware includes functional interfaces for different payment services, and the payment middleware is configured on an adaptation layer between the payment app and the framework of the electronic device, includes: The transaction initiation instruction is obtained through the payment APP, and the corresponding transaction process is started upon receiving the transaction initiation instruction; The payment middleware is invoked to match the target payment processing configuration corresponding to the transaction process. The transaction process is executed according to the target payment processing configuration to obtain the target business processing result, and the target business processing result is sent back to the payment APP.

2. The method according to claim 1, characterized in that, The step of invoking the payment middleware to match the target payment processing configuration corresponding to the transaction process includes: Obtain the card data corresponding to the transaction initiation command; The payment middleware is invoked to match the target payment processing configuration based on the card data, thereby obtaining the target payment processing configuration corresponding to the transaction process.

3. The method according to claim 2, characterized in that, The step of obtaining the card data corresponding to the transaction initiation instruction includes: The card processing interface of the payment middleware is invoked, and the transaction initiation command is sent to the hardware abstraction layer through the card processing interface; Receive the card data returned by the hardware abstraction layer after executing the transaction initiation instruction.

4. The method according to claim 2, characterized in that, The step of calling the payment middleware to match and obtain the target payment processing configuration corresponding to the transaction process based on the card data includes: Based on the target card organization in the card data, the transaction field parsing interface of the payment middleware is called to obtain the target transaction field specification adapted to the target card organization; Based on the target card organization, the key management interface of the payment middleware is invoked to obtain the target key configuration adapted to the target card organization; The target transaction field specification and the target key configuration are used as the target payment processing configuration corresponding to the transaction process.

5. The method according to claim 2, characterized in that, The step of executing the transaction process according to the target payment processing configuration to obtain the target business processing result includes: The transaction data in the transaction initiation instruction is obtained based on the card type in the card data. According to the target payment processing configuration, the transaction data is converted into a transaction message; The payment middleware's communication interface is invoked to send the transaction message to the acquiring institution corresponding to the card data, and the response message returned by the acquiring institution is received.

6. The method according to claim 5, characterized in that, The step of obtaining the transaction data in the transaction initiation instruction based on the card type in the card data includes: When the card type is a chip card, the card activation interface of the payment middleware is called to activate the chip card, and the application identifier of the chip card is obtained after the chip card is activated. Select the target card application in the chip card according to the application identifier; Call the card reading interface of the payment middleware to read the application data of the target card application; Call the card authentication interface of the payment middleware to perform cardholder verification based on the application data; The risk management interface of the payment middleware is invoked to perform terminal risk verification based on the terminal risk parameters in the target payment processing configuration. After the cardholder verification and terminal risk verification are both passed, the first transaction data is constructed based on the application data and the business data in the transaction initiation instruction, and the first transaction data is used as the transaction data in the transaction initiation instruction.

7. The method according to claim 5, characterized in that, The step of obtaining the transaction data in the transaction initiation instruction based on the card type in the card data includes: When the card type in the card data is a magnetic stripe card, the magnetic stripe card verification interface of the payment middleware is called to perform data integrity verification on the acquired card data; After the data integrity verification is passed, the main account number, card validity period, service code and verification value of the magnetic stripe card are extracted from the card data; The second transaction data is constructed based on the main account, card validity period, service code, verification value, and business data in the transaction initiation instruction, and the second transaction data is used as the transaction data in the transaction initiation instruction.

8. The method according to claim 4, characterized in that, Also includes: The transaction data in the transaction initiation instruction is obtained based on the card type in the card data. According to the target transaction field specification, the transaction data is reassembled to obtain the initial transaction message; Based on the target key configuration, the encryption interface of the payment middleware is invoked to encrypt the initial transaction message, resulting in the encrypted transaction message.

9. The method according to claim 8, characterized in that, Based on the target key configuration, the encryption interface of the payment middleware is invoked to encrypt the initial transaction message, resulting in the encrypted transaction message, including: Based on the target key configuration, determine the target key application partition and target key index corresponding to the transaction initiation instruction; Based on the target key application partition and the target key index, the encryption interface corresponding to the initial transaction message is invoked to encrypt the initial transaction message, thereby obtaining the encrypted transaction message.

10. An electronic device, characterized in that, include: The payment middleware is configured on the adaptation layer between the payment APP and the Framework of the electronic device, and the payment middleware includes functional interfaces for different payment services; The memory is configured to store executable programs; as well as A processor is configured to execute the program to perform a payment processing method according to any one of claims 1 to 9.

Images