EMV kernel cross-POS platform implementation architecture and methodology
By introducing a three-layer architecture into the EMV kernel, the input and output operation functions of the POS device are separated into the application (APP), which solves the problem of inconsistency of the EMV kernel on different POS devices and improves the universality of the kernel and development efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- AITIWEIER ELECTRONICS TECH BEIJING
- Filing Date
- 2022-11-28
- Publication Date
- 2026-06-23
Smart Images
Figure CN115756668B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of POS payment technology, specifically relating to an EMV kernel cross-POS platform implementation architecture and method. Background Technology
[0002] The EMV protocol specification establishes a unified standard for card and terminal interfaces in financial IC card payment systems, enabling all cards and terminals within this system to be interoperable. Furthermore, the adoption of this technology will significantly improve the security of bank card payments and reduce fraud. As banking applications become increasingly widespread, POS devices also need to support the EMV protocol specification.
[0003] The transaction process specified by the EMV protocol requires the joint completion of the POS device, smart card, and cardholder. During the transaction, the interfaces required for operations such as PIN input and signature are directly configured in the EMV kernel. However, due to the differences between the interfaces required for PIN input and signature operations on different POS devices, the EMV kernel running on different POS devices becomes inconsistent, resulting in low universality of the EMV kernel. Summary of the Invention
[0004] To address the shortcomings of existing technologies, this invention provides an EMV kernel implementation architecture and method across POS platforms, which can effectively solve the aforementioned problems.
[0005] The technical solution adopted in this invention is as follows:
[0006] This invention provides an implementation architecture for EMV kernel across POS platforms. The implementation architecture for EMV kernel across POS platforms includes a three-layer structure, which, from top to bottom, consists of: application (APP), kernel, and underlying interface.
[0007] The application (APP) defines different types of callback functions; the kernel implements the required functions by calling the callback functions of the application (APP).
[0008] The kernel implements the required functions by calling the underlying interface.
[0009] Preferably, the callback function implements the input and output operation functions of the POS device.
[0010] Preferably, the underlying interface implements the card reading function, security function and / or storage function of the POS device.
[0011] This invention also provides a method for implementing an EMV kernel across POS platforms, comprising the following steps:
[0012] Step 1: The interaction process between the kernel and the application (APP):
[0013] During POS transaction payment, when the kernel needs to obtain external input data or output data to the outside, the kernel sends a call instruction to the application APP to call the relevant callback function, wherein the call instruction carries the required basic data.
[0014] The application (APP) executes the relevant callback function according to the call instruction, obtains the execution result, and returns the execution result to the kernel.
[0015] Step 2, the interaction process between the kernel and the underlying interfaces:
[0016] During POS transaction payment, when the kernel needs the cooperation of the underlying interface, the kernel sends a call instruction to the corresponding underlying interface, wherein the call instruction carries the required basic data.
[0017] The underlying interface receives the call instruction, executes the corresponding function, and returns the execution result to the kernel.
[0018] Preferably, the callback functions in the application are pre-registered with the kernel, and the registration information includes: the function of the callback function and the address of the callback function;
[0019] Each underlying interface is pre-registered with the kernel, and the registration information includes the function of the underlying interface and the address of the underlying interface.
[0020] The cross-POS platform implementation architecture and method of EMV kernel provided by this invention have the following advantages:
[0021] This invention provides an EMV kernel implementation architecture across POS platforms, achieving kernel independence, reducing the coupling between the kernel and POS device hardware and applications, improving the kernel's versatility, reducing redundant kernel development, and increasing kernel development efficiency. Attached Figure Description
[0022] Figure 1 This is an architecture diagram of the cross-POS platform implementation architecture of the EMV kernel provided by the present invention.
[0023] Figure 2 This invention provides a specific payment transaction flowchart. Detailed Implementation
[0024] To make the technical problems solved, the technical solutions, and the beneficial effects of this invention clearer, the invention will be further described in detail below with reference to 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 invention.
[0025] This invention provides an EMV kernel implementation architecture across POS platforms. It separates the input and output operation functions of the POS device from the kernel and runs them in the application (APP). It also separates the underlying interfaces from the kernel, forming a lower-level interface layer. This achieves a three-layer architecture: the application (APP), the kernel, and the lower-level interfaces. This architecture enables kernel independence, reduces the coupling between the kernel and the POS device hardware and the application (APP), improves the kernel's versatility, reduces redundant kernel development, and increases kernel development efficiency.
[0026] refer to Figure 1 This invention provides an implementation architecture for EMV kernel across POS platforms. The implementation architecture for EMV kernel across POS platforms includes a three-layer structure, which, in a top-down direction, consists of: application (APP), kernel, and underlying interface.
[0027] The application (APP) defines different types of callback functions; the callback functions include, but are not limited to, implementing the input and output operation functions of the POS device.
[0028] The kernel implements the required functions by calling the callback function of the application (APP);
[0029] The kernel implements the required functions by calling the underlying interfaces. These underlying interfaces include, but are not limited to, implementing the card reading function, security function, and / or storage function of the POS device.
[0030] This invention also provides a method for implementing an EMV kernel across POS platforms, comprising the following steps:
[0031] Step 1: The interaction process between the kernel and the application (APP):
[0032] During POS transaction payment, when the kernel needs to obtain external input data or output data to the outside, the kernel sends a call instruction to the application APP to call the relevant callback function, wherein the call instruction carries the required basic data.
[0033] The application (APP) executes the relevant callback function according to the call instruction, obtains the execution result, and returns the execution result to the kernel.
[0034] In practical applications, the callback functions in the application (APP) are pre-registered with the kernel. The registration information includes the function of the callback function and the address of the callback function, thereby facilitating the kernel's invocation.
[0035] Step 2, the interaction process between the kernel and the underlying interfaces:
[0036] During POS transaction payment, when the kernel needs the cooperation of the underlying interface, the kernel sends a call instruction to the corresponding underlying interface, wherein the call instruction carries the required basic data.
[0037] The underlying interface receives the call instruction, executes the corresponding function, and returns the execution result to the kernel.
[0038] In practical applications, each underlying interface is pre-registered with the kernel. The registration information includes the function of the underlying interface and the address of the underlying interface, thereby facilitating kernel calls.
[0039] The following describes an example of an EMV kernel cross-POS platform implementation architecture for POS payments:
[0040] like Figure 2 As shown, it includes the following steps:
[0041] S1, kernel initialization, including loading the TLV space, the key, and other necessary parameters.
[0042] S2, the kernel completes the adaptation process with the application software running within the smart card by calling callback functions:
[0043] The kernel interacts with the application software running on the smart card through the APUD command to obtain the application software that matches the application software running on the smart card, and then runs it on the POS device.
[0044] During this process, the kernel calls the CallbackWaitAppSel() callback function, which allows the application (APP) to complete the adaptation process and return the result to the kernel.
[0045] S3, the kernel initializes the application software running on the smart card by calling callback functions:
[0046] The kernel sends the relevant PDOL data to the smart card by sending GPO instructions, thereby initializing the application software running on the smart card and obtaining the AIP and file storage identifier AFL returned by the smart card.
[0047] During this process, the kernel calls the CEmvReadSN() callback function, which allows the application (APP) to obtain the SN and return the result to the kernel.
[0048] S4, the kernel reads relevant data records from the smart card by calling callback functions:
[0049] The kernel reads the relevant data from the smart card one by one according to the File Storage Identifier (AFL) returned by the smart card, and stores the read data in the TLV space.
[0050] In S5, the kernel completes the offline data authentication process by calling a callback function.
[0051] The kernel performs the correct offline data verification based on the AIP data returned by the smart card. According to the EMV specification, offline data verification can be SDA, DDA, or CDA. If CDA is the preferred method, it will actually be executed after GAC.
[0052] In S6, the kernel completes the compatibility check process by calling callback functions.
[0053] The kernel performs three compatibility checks: application version number check, application usage control check, and application activation / expiration date check.
[0054] In S7, the kernel completes the cardholder authentication process by calling callback functions.
[0055] The kernel selects to perform authentication such as offline PIN processing, online PIN processing, or signature processing based on the AIP, CVM list, and terminal capabilities.
[0056] The kernel calls the CallbackEmvGetHolderPwd() callback function, prompting the application (APP) to input a PIN code or signature information, and then returns the obtained information to the kernel.
[0057] In S8, the kernel completes the risk management process by calling callback functions.
[0058] Risk management specifically includes lower limit checks, random transaction selection, and speed checks. Under random transaction selection, online transactions may be required if the authorized amount meets the conditions.
[0059] In S9, the kernel completes the terminal behavior analysis process by calling callback functions.
[0060] During this process, the kernel activates the smart card by sending the Generate AC command through a callback function to perform action analysis in order to retrieve the transaction results from the first step.
[0061] S10, Online Processing Process
[0062] During this process, the terminal will send the data required by the transaction backend, and the backend will make a judgment on the transaction result based on the data and return it to the terminal.
[0063] S11, invoking the kernel completion process.
[0064] During this process, the terminal sends a second Generate AC command based on the execution results of the above steps to determine the final transaction result.
[0065] S12, S13, S14: The transaction ends, and the transaction results are displayed.
[0066] In the above scenario, the kernel operation involves cardholder interactions with the POS device and calls to some underlying interfaces related to the POS device. These operations are integrated together. In traditional solutions, these operations are all executed by the kernel. However, for newly developed device models, even if the EMV specification remains unchanged, the entire kernel needs to be redeveloped and adapted, which is a complex process.
[0067] Specifically, because the S2, S3, and S7 processes involve operations performed on the POS device by cardholders and acquiring bank staff, including interface display and input, these operations are implemented through the kernel. This requires the kernel to be adapted to different devices, resulting in low universality of the kernel code.
[0068] In this invention, the functions corresponding to these processes are defined as callback functions, and these callback functions are configured in the application (APP). The application implements the relevant functions, and the kernel only needs to call the callback functions. Therefore, it is equivalent to separating the relevant operations of cardholder-POS device interaction from the kernel. These operations can be uniformly implemented by the application without modifying the kernel process. When developing on new devices, it can be completed simply by adapting the application without modifying the kernel, thereby improving the versatility of the kernel.
[0069] The callback function is implemented using a function pointer. By default, the function pointer points to an empty function or a default callback function. If the application layer doesn't implement one, the default callback function is used. If the application needs customization, the application layer implements the custom callback function, and the kernel sets the function pointer to point to the custom callback function. At runtime, the kernel initiates the call to the callback function, the application runs the callback function, and returns the execution result to the kernel. Therefore, customization needs for different clients can be met through the application without modifying the kernel for each customization.
[0070] Similarly, in the kernel transaction process, there are some low-level interfaces related to POS devices, such as card reading interfaces, security interfaces, and storage interfaces. In this invention, the kernel calls the low-level interfaces to improve the versatility of the kernel.
[0071] Therefore, this invention provides an EMV kernel implementation architecture across POS platforms, in which some functions are implemented through callback functions and run by the application (APP); and some functions are implemented through underlying interfaces. Thus, the kernel only needs to call the callback functions and underlying interfaces, thereby separating the callback functions and underlying interfaces from the kernel and enabling the reuse of kernels for different POS platforms.
[0072] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A payment method based on an EMV kernel cross-POS platform implementation architecture, characterized in that, The cross-POS platform implementation architecture of the EMV kernel includes a three-layer structure, which, from top to bottom, consists of: application (APP), kernel, and underlying interface. The application (APP) defines different types of callback functions; the kernel implements the required functions by calling the callback functions of the application (APP); the callback functions implement the input and output operation functions of the POS device. The kernel implements the required functions by calling the underlying interface; the underlying interface implements the card reading function, security function and / or storage function of the POS device. The method includes the following steps: S1, Kernel initialization, including loading the TLV space, the key, and other necessary parameters; S2, the kernel completes the adaptation process with the application software running in the smart card by calling callback functions; The kernel interacts with the application software running on the smart card through the APUD command to obtain the application software that matches the application software running on the smart card, and then runs it on the POS device. During this process, the kernel calls the CallbackWaitAppSel() callback function, the application (APP) completes the adaptation process, and returns the result to the kernel. S3, the kernel completes the initialization process of the application software running on the smart card by calling callback functions; The kernel sends the relevant PDOL data to the smart card by sending the GPO command, thereby initializing the application software running on the smart card and obtaining the AIP and file storage identifier AFL returned by the smart card. During this process, the kernel calls the CEmvReadSN() callback function, which allows the application (APP) to obtain the SN and return the result to the kernel. S4, the kernel reads relevant data records from the smart card by calling callback functions; The kernel reads the relevant data from the smart card one by one according to the file storage identifier (AFL) returned by the smart card, and stores the read data in the TLV space; In S5, the kernel completes the offline data authentication process by calling a callback function; The kernel performs the correct offline data verification based on the AIP data returned by the smart card. According to the EMV specification, offline data authentication is SDA, DDA, or CDA; if CDA is the preferred method, it will actually be executed after GAC. In S6, the kernel completes the compatibility check process by calling callback functions; The kernel performs three compatibility checks: application version number check, application usage control check, and application activation / expiration date check. In S7, the kernel completes the cardholder authentication process by calling callback functions; The kernel selects to perform offline PIN processing, online PIN processing, or signature processing authentication based on the AIP, CVM list, and terminal capabilities. The kernel calls the CallbackEmvGetHolderPwd() callback function to make the application (APP) input a PIN code or signature information, and returns the obtained information to the kernel. In S8, the kernel completes the risk management process by calling callback functions; Risk management specifically includes lower limit checks, random transaction selection, and speed checks; under random transaction selection processing, if the authorized amount meets the conditions, online transactions may be required. In S9, the kernel completes the terminal behavior analysis process by calling callback functions; During this process, the kernel activates the smart card by sending the Generate AC command through a callback function to perform action analysis in order to retrieve the transaction results from the first step. S10, Online processing procedure; During this process, the terminal will send the data required by the transaction backend, and the backend will make a judgment on the transaction result based on the data and return it to the terminal. S11, invokes the kernel completion process; During this process, the terminal sends a second Generate AC command based on the execution results of the above steps to determine the final transaction result.