Aggregation acquiring system and method

Abstract

The invention discloses an aggregation acquiring system and method. The system comprises an aggregation acquiring application; the aggregation acquiring application further comprises a common area program and a safe area program; the common area program runs in a rich execution environment, and the safe area program runs in a protected virtual machine; the protected virtual machine comprises a plurality of first sandbox environments; and acquiring applications of different acquiring mechanisms are operated in each first sandbox environment. The security of the transaction processing process can be improved.

Description

Technical Field

[0001] This invention relates to the field of electronic payment technology, and in particular to an aggregated payment system and method. Background Technology

[0002] With the rapid development of electronic payments, aggregated payment technology, by integrating multiple payment channels, has become the mainstream payment solution. Currently, common implementation methods for aggregated payment include API calls and SDK integration. The former completes payment scheduling by the application calling the aggregation platform's interface, while the latter integrates multiple payment SDKs to form a unified service interface. However, in these traditional solutions, the payment application runs in an open, rich execution environment, and even with security technologies such as TEE, it still faces the risk of system attacks. Summary of the Invention

[0003] The technical problem to be solved by the present invention is: an aggregated acquiring system and method that can improve the security of the transaction processing process.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: The aggregated acquiring application includes a normal zone program and a secure zone program; The ordinary zone program runs in a rich execution environment, while the secure zone program runs in a protected virtual machine; The protected virtual machine also includes multiple first sandbox environments; Each of the first sandbox environments runs acquiring applications from different acquiring institutions.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An aggregated payment collection method, applied to the aforementioned aggregated payment collection system, the method comprising: The normal zone program receives an acquiring request for the target acquiring institution to perform acquiring services, parses the acquiring request to obtain the target scheduling mode, and loads the protected virtual machine to connect to the secure zone program; If the target scheduling mode is background scheduling, the security zone program executes the acquiring service through the aggregate acquiring background. If the target scheduling mode is local scheduling, the security zone program executes the acquiring service through the acquiring application of the target acquiring institution.

[0006] The beneficial effects of this invention are as follows: By using the isolation mechanism of a protected virtual machine, the aggregated acquiring application is divided into programs running in both a normal zone and a secure zone, thereby enhancing the security of the transaction processing process. The normal zone program, operating in an open, rich execution environment, is responsible for receiving acquiring requests and determining the target scheduling mode, ensuring the adaptability of call paths across different scenarios. Simultaneously, by loading the protected virtual machine and connecting with the secure zone program, it avoids directly exposing core processing logic. The secure zone program runs within the protected virtual machine, dynamically calling the aggregated acquiring backend or the acquiring application to execute acquiring services based on the target scheduling mode. These acquiring services are also set up in the secure environment, ensuring that sensitive transaction operations are executed in a secure, isolated environment. Furthermore, the sandbox environment under virtualization technology isolates the transaction processing processes of different acquiring institutions, avoiding the risk of cross-platform data leakage and improving the security of the transaction processing process. Attached Figure Description

[0007] Figure 1 This is a schematic diagram of the architecture of an aggregated payment collection system provided in an embodiment of the present invention; Figure 2 This is another schematic diagram of an aggregated payment collection system provided in an embodiment of the present invention; Figure 3 This is a flowchart of an aggregated payment collection method provided in an embodiment of the present invention. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] Explanation of professional names

[0010] With the widespread adoption of electronic payments, electronic acquiring has become the mainstream payment method. To address the complexity of acquiring business brought about by the diversification of payment channels, aggregated acquiring, as a solution that integrates multiple heterogeneous payment channels and provides merchants with a unified technical interface and business process, has become a key technology path in the industry and is widely used. Currently, common aggregated acquiring implementation solutions in the industry can be mainly summarized into the following two categories: One approach is API-based aggregated payment processing. In this solution, the acquiring application calls the application programming interface (API) provided by the aggregated payment processing backend to upload parameters such as transaction amount, merchant identification information, and basic order information. After receiving the information, the backend executes the scheduling logic and forwards the payment request to the corresponding acquiring channel, thereby completing the entire payment processing flow.

[0011] The second approach is SDK-integrated aggregated payment processing. In this solution, the aggregated payment processing application first integrates the payment software development kits (SDKs) provided by each independent payment processing channel, and then encapsulates them into a unified aggregated payment processing SDK. By integrating and calling this aggregated payment processing SDK, the payment processing application can provide merchants with a unified payment processing service interface, enabling aggregated processing of multiple payment processing channels.

[0012] However, in actual deployment and application, existing aggregated payment solutions still have limitations: Firstly, regarding data governance, existing solutions all require the aggregated acquiring backend to be deeply involved in the management process of merchant and transaction information, resulting in relevant data having to be transferred through the aggregated acquiring backend. This architecture has raised concerns among some acquiring institutions about data security and their autonomy in data control. These institutions expect their core data to be directly transmitted to their own platforms, rather than flowing through third-party aggregation platforms, in order to strengthen their independent control over data resources and reduce the risk of data leakage and unauthorized use.

[0013] Secondly, at the system security level, existing acquiring applications typically run in Rich Execution Environments (REEs). This environment is highly exposed and faces significant risks of malware attacks and data theft. Although the industry currently widely employs technologies such as Trusted Execution Environments (TEEs) or Secure Elements (SEs) to protect sensitive data, it is still difficult to provide sufficient security for the entire acquiring transaction process. Once the REE-side system or the acquiring application itself is subjected to malicious attacks, it could still pose a substantial threat to the financial security of merchants and consumers.

[0014] Furthermore, at the terminal application level, due to numerous differences and limitations among different acquiring institutions in terms of key management systems, terminal management strategies, and application distribution mechanisms, existing terminal acquiring applications typically belong only to a specific acquiring institution or aggregated acquiring backend. Acquiring applications from different institutions or platforms cannot coexist on the same acquiring terminal. When merchants need to switch acquiring service providers, they often have to return the terminal equipment to the factory for a so-called "transfer" operation. This process is not only time-consuming and labor-intensive but also significantly increases the merchant's operating costs and business interruption risk.

[0015] To solve the above problems, refer to Figure 1 Embodiments of the present invention provide an aggregated acquiring system, which includes an aggregated acquiring application. The aggregated acquiring application includes a normal zone program and a secure zone program. The normal zone program runs in a rich execution environment, and the secure zone program runs in a protected virtual machine. The protected virtual machine also includes multiple first sandbox environments, each of which runs acquiring applications from different acquiring institutions. Figure 1 In this case, N is an integer greater than 2.

[0016] The rich execution environment (REA) refers to a runtime environment with full operating system functionality, specifically implemented using Android or Linux systems, used for executing non-sensitive business logic processing. A protected virtual machine (VM) refers to a secure execution environment isolated through virtualization framework technology, specifically Android's AVF. A general-purpose application refers to a program module running within the general-purpose operating system of the REA. A secure application refers to a program module running within the secure operating system of the protected VM. An acquiring institution refers to a financial institution providing acquiring services; each acquiring institution has an independent transaction processing interface. A sandbox environment refers to an isolated, independent runtime environment created within the protected VM. Each sandbox environment is specifically designed to run the acquiring application of a particular acquiring institution to store sensitive information from the acquiring application. An acquiring application refers to a customized program matched to the specific business logic of a acquiring institution, used to adapt to the transaction protocols of different acquiring platforms.

[0017] In a specific application scenario, each acquiring application is assigned to run in an independent first sandbox environment. Sensitive data includes, but is not limited to, merchant identity identifiers, transaction keys, and session tokens, which are isolated within their respective first sandbox environments during storage. For example, during the acquiring request processing, if the target acquiring institution is institution A, access is only permitted to the first sandbox environment storing institution A's data; if the target acquiring institution is institution B, access is only permitted to the first sandbox environment storing institution B's data. Through the access control mechanism of the first sandbox environment, different local acquiring applications cannot read or modify the sensitive data of other applications across environments.

[0018] As described above, by using the isolation mechanism of the protected virtual machine, the aggregated acquiring application is divided into programs running in both a normal zone and a secure zone, thereby enhancing the security of the transaction processing process. The normal zone program, operating in an open, rich execution environment, is responsible for receiving acquiring requests and determining the target scheduling mode, ensuring the adaptability of call paths across different scenarios. Simultaneously, by loading the protected virtual machine and connecting with the secure zone program, it avoids directly exposing core processing logic. The secure zone program runs within the protected virtual machine, dynamically calling the aggregated acquiring backend or the acquiring application to execute acquiring services based on the target scheduling mode. This ensures that sensitive transaction operations are executed in a secure, isolated environment. Furthermore, the sandbox environment under virtualization technology isolates the transaction processing processes of different acquiring institutions, avoiding the risk of cross-platform data leakage and improving the security of the transaction processing process.

[0019] In one embodiment of this application, the system further includes a hardware security zone comprising multiple second sandbox environments; each second sandbox environment stores key information for different acquiring institutions. A connection is established between the first and second sandbox environments of the same acquiring institution. This ensures that access can only be granted to the first and second sandboxes corresponding to the same acquiring institution.

[0020] The hardware security zone refers to a physically isolated and protected area built upon hardware security modules or chips. It possesses the capability to resist physical probing and side-channel attacks, and can be implemented through a TEE (Trusted Execution Environment) or SE (Secure Element), providing hardware-level security protection for key management. Key information refers to the core key materials used by acquiring institutions for transaction data encryption / decryption and digital signature generation / verification, including but not limited to symmetric encryption keys, asymmetric encryption private keys, and certificates. Different acquiring institutions use different key download protocols, applications, and management platforms. Therefore, each acquiring institution's key information is independently stored in a dedicated second sandbox environment, with hardware isolation mechanisms preventing unauthorized access or export of the keys.

[0021] As described above, by leveraging the physical isolation characteristics of the hardware security zone, key information from different acquiring institutions is stored in independent second sandbox environments, achieving hardware-level security protection for key storage. The hardware security zone, based on the encryption engine and access control mechanism of the security chip, ensures that key generation, storage, and usage are all conducted in a physically isolated environment, effectively defending against malicious attacks and physical probing at the operating system level. Each second sandbox environment forms a logical mapping with the first sandbox environment in the protected virtual machine. During transaction processing, the corresponding acquiring institution's key is accessed on demand through a secure channel, ensuring both the integrity and confidentiality of key materials and maintaining the continuity of the transaction process. Only the first and second sandbox environments corresponding to the same acquiring institution can connect, isolating the environments of different acquiring institutions.

[0022] In a specific application scenario, the aggregated acquiring system provided by this invention is applied to an acquiring device that supports Android AVF. (See reference...) Figure 2The system creates and maintains a Rich Execution Environment (REE) and a Protected Virtual Machine (pVM), which are isolated from the REE. The system includes an aggregated acquiring application, which comprises a normal zone program and a secure zone program. The normal zone program runs on the general operating system (NormalOS) of the REE, while the secure zone program runs on the secure operating system (MicroOS) of the protected virtual machine (pVM). MicroOS includes MicroDroid OS within Android AVF. Furthermore, within the protected virtual machine, four mutually isolated first sandbox environments are created, each constituting an independent runtime container. In the specific deployment of the first sandbox environments, acquiring applications from different acquiring institutions run. Specifically: first sandbox environment one runs acquiring application A, first sandbox environment two runs acquiring application B, first sandbox environment three runs acquiring application C, and first sandbox environment four runs acquiring application D. Each primary sandbox environment provides independent storage space for the acquiring applications running within it, specifically for storing the acquiring institution's sensitive information (such as merchant keys and transaction records), achieving secure isolation of data across acquiring institutions. In addition, the system includes a hardware security zone, specifically a Trusted Execution Environment (TEE) or a Secure Element (SE). For high-security key information (such as payment passwords and private keys), it is stored in the TEE or SE sandbox environment, protected by hardware encryption, isolating secure data between different acquiring institutions, and managing application data access to prevent cross-institutional access to sensitive data.

[0023] In one optional implementation, the ordinary zone program includes a scheduling control module and a pVM management module. The scheduling control module receives acquiring requests from the target acquiring institution to perform acquiring services and parses the acquiring requests to obtain the target scheduling mode. The pVM management module loads a protected virtual machine to connect to the secure zone program. The ordinary zone program provides the relevant application programming interfaces (APIs) required by the merchant application for acquiring transactions, such as acquiring, canceling, and querying orders. The secure zone program includes an authentication module, a background scheduling module, and a local scheduling module. The authentication module obtains a second verification key corresponding to the first verification key from the second storage area in the hardware security zone, decrypts the request ciphertext based on the second verification key to obtain application information and the acquiring request, and verifies the legality of the application information. The background scheduling module executes acquiring services through the aggregated acquiring backend. The local scheduling module executes acquiring services through the acquiring application of the target acquiring institution. The background scheduling module includes an acquiring request module and a security risk control module. The acquiring request module converts the acquiring request into a standard interface request of the aggregated acquiring backend and calls the target acquiring platform corresponding to the target acquiring institution to perform acquiring services based on the standard interface request. The security risk control module is used to manage the risks of accessing the aggregated payment backend, and to manage the application operating environment and user request behavior.

[0024] Compared to existing technologies, traditional solutions process the entire transaction process in a single environment, making them vulnerable to exploitation by attackers to steal sensitive data. This solution employs a dual-execution environment architecture, deploying core transaction scheduling within a protected virtual machine, creating a physically isolated security barrier. The ordinary zone program retains only basic communication functions, while the secure zone program uses virtualization technology to achieve logical isolation between the businesses of different acquiring institutions. This design ensures that even if the ordinary zone is compromised, attackers cannot directly access the key storage and transaction processing data in the secure zone.

[0025] To solve the above problems, refer to Figure 3 Another embodiment of the present invention provides an aggregated acquiring method, which includes an aggregated acquiring system as described above, and includes steps 110-130.

[0026] Step 110: The normal zone program receives an acquiring request for the target acquiring institution to perform acquiring services, parses the acquiring request to obtain the target scheduling mode, and loads the protected virtual machine to connect to the security zone program.

[0027] Step 120: If the target scheduling mode is background scheduling, the security zone program executes the acquiring service through the aggregate acquiring background.

[0028] Step 130: If the target scheduling mode is local scheduling, the security zone program executes the acquiring service through the acquiring application of the target acquiring institution.

[0029] In this context, the target acquiring institution refers to the acquiring institution designated by the merchant to handle the transaction within a single acquiring transaction process. The target scheduling mode refers to the service routing strategy derived from the acquiring request parsed by the ordinary zone program, instructing the security zone program on the appropriate path to execute the acquiring service. Specific modes include backend scheduling and local scheduling. Backend scheduling forwards the acquiring request to the aggregated acquiring backend for unified processing, suitable for standardized transaction processes or scenarios requiring platform-level risk control integration. Local scheduling involves the security zone program directly calling the acquiring application of a specific acquiring institution running within a protected virtual machine sandbox, suitable for scenarios requiring direct interaction with the acquiring institution or the use of localized security components. The aggregated acquiring backend refers to the unified scheduling platform deployed on the server side.

[0030] In one alternative implementation, merchants can initiate an acquiring request through their merchant application within the system, requesting the target acquiring institution to perform acquiring services. The merchant application refers to the application that needs to use the aggregated acquiring function, specifically including the merchant's business and payment collection components. When the merchant application needs to perform acquiring-related functions, it does so by calling the interfaces provided by the aggregated acquiring SDK. Specifically, in response to the merchant's acquiring operation, the merchant application calls the full aggregated acquiring application programming interface (API) provided by the regular application of the aggregated acquiring application. For example, if the merchant application is a POS system, the full aggregated acquiring API is startPayment(amount, merchantInfo, orderInfo, payMethod), where the API information includes amount (payment amount), merchantInfo (merchant information), orderInfo (order information), and payMethod (payment method).

[0031] As described above, the ordinary zone program dynamically determines the target scheduling mode by parsing the acquiring request, achieving intelligent adaptation of transaction paths and efficient resource scheduling. The ordinary zone program completes request reception and mode parsing in a rich execution environment and establishes a secure connection with the secure zone by loading a protected virtual machine, ensuring the isolation and controllability of sensitive operation entry points. The secure zone program performs differentiated processing according to the target scheduling mode: in background scheduling mode, it processes acquiring services uniformly through the aggregated acquiring backend, fully utilizing the risk control and routing capabilities of the aggregated acquiring backend; in local scheduling mode, it directly calls the acquiring application of the target acquiring institution in the sandbox environment, meeting the low latency or data security needs of specific institutions. Both paths run in the secure isolation environment of the protected virtual machine, ensuring the security of core transaction logic and sensitive data processing, and improving the system's adaptability to different acquiring scenarios through the pattern-based scheduling mechanism.

[0032] In one embodiment of this application, in step 120, the method by which the security zone program executes acquiring services through the aggregate acquiring backend includes steps 210-220.

[0033] Step 210: The security zone program converts the acquiring request into a standard interface request for the aggregated acquiring backend, wherein the standard interface request includes the institution identifier of the target acquiring institution.

[0034] Step 220: Request and call the aggregated acquiring backend based on the standard interface to instruct the aggregated acquiring backend to call the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service according to the institution identifier.

[0035] Backend scheduling is suitable for scenarios where merchants require additional services from the aggregated payment backend. For example, if a merchant needs additional order management services from the aggregated payment backend, then backend scheduling is necessary. Standard interface requests refer to request formats that conform to the predefined data structure of the aggregated payment backend. Specifically, data can be encapsulated using JSON or XML protocols, and parameters such as merchant ID, amount, and payment method in the original payment request can be converted into standard fields through field mapping rules. The target payment platform refers to the business processing system provided by the payment acquiring institution. This can be implemented using a distributed microservice architecture, with each payment acquiring platform having an independent service address and authentication mechanism.

[0036] In a specific application scenario, when the target scheduling mode is background scheduling, the security zone program first parses the merchant identity, transaction amount, and target acquiring institution code carried in the acquiring request. Then, according to preset conversion rules, it maps the heterogeneous original request parameters to the field structure defined by the standard interface. For example, it unifies the different naming conventions for "payment amount" across different institutions into the "amount" field. The converted standard request is transmitted to the aggregated acquiring backend through an encrypted channel. The backend selects the corresponding institution adaptation module based on the target acquiring institution code and calls the target acquiring platform's open interface to execute the transaction. During this process, the security zone program only exposes the standard interface without directly interfacing with the specific interface protocols of each acquiring institution, effectively isolating the impact of underlying interface changes on the upper-layer system.

[0037] Compared with existing technologies, this application implements a model in which the acquiring platform is scheduled by the aggregate acquiring backend in pVM. Acquiring requests and data are transmitted directly through the network connection established between pVM and the aggregate acquiring backend, avoiding data exposure in an open rich execution environment, effectively reducing the risk of data leakage, and providing higher security for acquiring transactions.

[0038] As can be seen from the above implementation methods, by establishing a standardized interface conversion mechanism, the system coupling problem caused by differences in different interfaces during traditional backend scheduling is solved. Specifically, when the system determines that it is currently in backend scheduling, the security zone program first converts the heterogeneous acquiring requests initiated by merchants into standard interface requests that conform to the definition of the aggregated acquiring backend. This conversion process achieves the normalization of different interface protocols, so that subsequent calls do not need to pay attention to the interface differences of specific acquiring platforms. Based on the standard interface request, the target acquiring platform is called. Through the aggregated acquiring backend, the standardization of the request format is ensured, and the risk of directly exposing the interface details of each acquiring institution is reduced. By combining standardized conversion with centralized scheduling, the system's compatibility with different acquiring institutions and the security of interface calls are effectively improved while ensuring transaction processing efficiency.

[0039] In one embodiment of this application, in step 130, the method by which the security zone procedure performs acquiring services through the acquiring application of the target acquiring institution includes steps 310-320.

[0040] Step 310: The secure zone program starts the acquiring application of the target acquiring institution and determines the second sandbox environment corresponding to the target acquiring institution based on the signature information of the acquiring application.

[0041] Step 320: The secure zone program reads the target key information of the target acquiring institution from the second sandbox environment, and calls the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service based on the acquiring application and the target key information.

[0042] Local scheduling is suitable for scenarios where merchants expect a secure and stable payment environment and low operating costs. For example, if a merchant does not want to invest too much in operating costs and wants to improve data privacy, then the merchant needs to use local scheduling.

[0043] In one optional implementation, the key information in the second sandbox environment includes a master key and a working key. Different acquiring institutions often use different key download protocols, applications, and key management platforms for their master keys. The TEE area is divided into multiple second sandbox environments, each storing the master keys and working keys of different acquiring institutions. The master keys for multiple acquiring institutions can be injected at the factory or before deploying merchant applications. The working keys are downloaded and stored in the corresponding second sandbox environment for each acquiring institution according to the multi-acquiring institution management mechanism of the SE area.

[0044] In a specific application scenario, when the target scheduling mode is local scheduling, the secure zone program starts an acquiring application instance bound to the target acquiring institution's code within the protected virtual machine. This instance establishes a direct connection with the target acquiring platform through a pre-built secure communication protocol. After the acquiring request data undergoes format conversion within the protected virtual machine, it is sent by the acquiring application to the target acquiring platform through an encrypted channel. The entire transaction voucher return process is processed within the virtual machine's encrypted memory area.

[0045] Compared to existing technologies, this application achieves local scheduling via pVM, enabling merchants to select specific acquiring applications based on their needs and directly initiate acquiring requests and transmit data through the network connection established between pVM and the acquiring platform. This flexible scheduling mechanism allows merchants to switch acquiring institutions more conveniently, eliminating the need for cumbersome machine return and switching operations, significantly improving business operation efficiency. Furthermore, it avoids the security risks associated with data transfer through aggregated acquiring platforms and effectively accommodates the data control security requirements of some acquiring institutions.

[0046] As can be seen from the above implementation method, firstly, when the scheduling mode is local scheduling, operations are executed in an isolated, protected virtual machine environment to avoid direct exposure to an open, rich execution environment. Secondly, the acquiring application corresponding to the target acquiring institution is started, and the virtual machine environment is used to isolate and protect the application's operation, preventing malicious programs from tampering with the transaction process. Finally, based on the acquiring application directly calling the target acquiring platform, a trusted connection channel is established while ensuring the integrity of the application. This achieves both the connection with different acquiring institution platforms and avoids the security risks brought about by aggregating data from the acquiring platform through local scheduling. Among these, the protected virtual machine, as a trusted execution environment, provides hardware-level security protection for the acquiring application, while the local application deployment method corresponding to the institution achieves physical isolation of the business logic of different acquiring institutions.

[0047] It should be noted that the service fees charged to merchants may vary depending on the operating costs of the aggregated payment backend. Furthermore, the efficiency and stability of the acquiring institution's operations also depend on the aggregated payment backend. Local scheduling, on the other hand, involves a direct connection between the system and the acquiring institution. Therefore, the aggregated acquiring mechanism described in this application allows merchants to choose the appropriate scheduling mode as needed. For example, merchants requiring more services such as order management from the aggregated payment backend can choose backend scheduling. If merchants consider acquiring stability and service fees, they can choose suitable local scheduling. Based on this, merchants can either manually select the appropriate mode or extend other scheduling strategies to automatically select the optimal one.

[0048] In one embodiment of this application, the method further includes steps 410-420.

[0049] Step 410: The ordinary zone program obtains the application information of the acquiring request and obtains the first verification key from the first storage area in the hardware security zone.

[0050] Step 420: The ordinary zone program encrypts the application information and acquiring request based on the first verification key, obtains the request ciphertext, and sends the request ciphertext to the secure zone program.

[0051] The application information refers to the identity and permission configuration data of the application initiating the acquiring request. This can be implemented using the application package name, digital certificate, or unique identifier, and is used to verify the application's legitimacy. The first verification key is the cryptographic key used for data encryption. This can be implemented using an AES key for symmetric encryption or an RSA public key for asymmetric encryption, and is isolated and protected in a secure storage area within a trusted execution environment to prevent the key from being stolen by malicious programs. The request ciphertext refers to the encrypted result of the application information and the acquiring request. This can be implemented using CBC or GCM encryption modes combined with HMAC integrity verification to ensure that the data is not tampered with or leaked during transmission.

[0052] In a specific application scenario, after receiving a payment request from a merchant application, the ordinary zone program first extracts the application information, such as the application package name and digital certificate. Then, the ordinary zone program accesses the first storage area in the hardware secure zone through a secure interface to obtain a pre-stored first verification key. This key is used to jointly encrypt the application information and the payment request, generating a request ciphertext containing ciphertext and an integrity checksum. The encryption process is completed within the secure boundary of the trusted execution environment, ensuring that the key is not exposed in the ordinary execution environment. After encryption, the ordinary zone program transmits the request ciphertext to the secure zone program running on a protected virtual machine via inter-process communication or a secure channel. Upon receiving the request ciphertext, the secure zone program verifies the integrity and legitimacy of the data's origin through a decryption and verification process, thereby avoiding the risk of man-in-the-middle attacks or data tampering.

[0053] As described above, by first obtaining application information, the source of the acquiring request can be traced, providing a data foundation for subsequent legitimacy verification. A first verification key is obtained from the first storage area within the hardware security zone, and the key storage is physically isolated from the ordinary execution environment to prevent the key from being stolen by malicious programs. Based on the first verification key, the application information and the acquiring request are jointly encrypted to generate ciphertext, ensuring the confidentiality and integrity of sensitive data during transmission and preventing data leakage or tampering caused by man-in-the-middle attacks. The ciphertext is sent to a program running in the security zone of a protected virtual machine. Utilizing the dual security barriers of the trusted execution environment and the protected virtual machine, end-to-end protection of transaction data during cross-environment transmission is ensured.

[0054] In one embodiment of this application, the method further includes steps 510-530.

[0055] Step 510: The security zone program obtains the second verification key corresponding to the first verification key from the second storage area in the hardware security zone, and decrypts the request ciphertext based on the second verification key to obtain the application information and the acquiring request, and verifies the legality of the application information.

[0056] Step 520: If the application information passes the validity check, the security zone program executes the acquiring service through the aggregate acquiring backend or the acquiring application of the target acquiring institution.

[0057] Step 530: If the application information fails the validity check, the security zone program will prohibit the execution of the acquiring service.

[0058] The second storage area refers to an encrypted storage area within the hardware security area, independent of the first storage area. Specifically, it can be implemented using isolated areas defined by the hardware security module. This area stores the asymmetric key paired with the first verification key, ensuring physical isolation between the key storage and the ordinary area. The second verification key is the decryption key that forms an asymmetric encryption relationship with the first verification key used in the ordinary area. Specifically, it can be implemented using a private key generated by the RSA algorithm. This key is used to decrypt the request ciphertext encrypted by the first verification key, forming a two-way key verification mechanism. The application information legitimacy verification refers to verifying the merchant application's identity, digital signature, or authorization credentials. This can be implemented using digital certificate verification or hash value comparison to confirm the legitimacy and integrity of the request source.

[0059] In a specific application scenario, after the ordinary zone program transmits the encrypted request ciphertext to the secure zone program, the secure zone program retrieves the second verification key from the second storage area of ​​the hardware secure zone and restores the original application information and acquiring request through asymmetric decryption. Subsequently, it performs digital signature verification on the merchant identity identifier in the application information, for example, by comparing the pre-stored certificate with the signature hash value in the request. If the verification passes, the subsequent transaction process is triggered; if a signature mismatch or certificate expiration is found, the transaction execution is immediately terminated. This process prevents key leakage risks through separate key storage, ensures data transmission security through asymmetric encryption and decryption, and blocks the execution path of unauthorized requests through a dual verification mechanism.

[0060] As described above, obtaining the second verification key from the second storage area within the hardware security zone physically isolates the key storage from the ordinary area, avoiding the risk of key leakage. The second verification key, corresponding to the first verification key, decrypts the request ciphertext, forming an encrypted verification mechanism to ensure data integrity and confidentiality during transmission. Verifying the legitimacy of application information identifies the authenticity of the merchant's identity, preventing unauthorized applications from forging payment requests. The transaction execution process is dynamically controlled based on the verification results, immediately blocking the transaction link upon detecting an illegal request, forming a closed-loop security protection. This application effectively guarantees the legitimacy of the caller's identity and improves the security of the transaction process through the synergistic effect of key separation storage, encryption / decryption, and legitimacy verification.

[0061] In one embodiment of this application, in step 210, the method of the security zone program requesting and calling the target acquiring platform corresponding to the target acquiring institution to perform acquiring services based on the standard interface includes step 610.

[0062] Step 610: The secure zone program establishes a first network connection channel with the aggregated acquiring backend through the system network service, and sends the standard interface request to the aggregated acquiring backend in encryption based on the first network connection channel, so as to call the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service through the aggregated acquiring backend.

[0063] The first network connection channel refers to the encrypted communication link established through the system network service from the secure zone program to the aggregate acquiring backend. Specifically, it can be implemented using the TLS protocol to isolate external network interference and prevent man-in-the-middle attacks.

[0064] As can be seen from the above implementation method, the dedicated first network connection channel established through the system network service enables point-to-point communication between the secure zone program and the aggregated acquiring backend, avoiding the risk of man-in-the-middle attacks in traditional open network environments. Encryption of standard interface requests ensures the confidentiality of transaction data during transmission, preventing the theft or tampering of sensitive information.

[0065] In one embodiment of this application, step 320, the method of the secure zone program calling the target acquiring platform corresponding to the target acquiring institution to perform acquiring services based on the acquiring application and target key information, includes step 710.

[0066] Step 710: The secure zone program establishes a second network connection channel with the target acquiring platform corresponding to the target acquiring institution by calling the system network service through the acquiring application, and directly calls the target acquiring platform to execute acquiring services based on the second network connection channel and the target key information.

[0067] The second network connection channel refers to the encrypted communication link established through the system network service from the secure zone program to the target acquiring platform. This channel is only accessible to authenticated acquiring applications.

[0068] As described above, the legitimacy of network connection requests is ensured by having the acquiring application call the system's network services. This application restricts system network service access permissions to the acquiring application, preventing unauthorized access to the network channel by irrelevant programs. This design, while ensuring transaction efficiency, constructs an end-to-end security protection system through the synergy of the secure zone program and the dedicated network channel.

[0069] In one embodiment of this application, in step 310, the method by which the security zone procedure determines the second sandbox environment corresponding to the target acquiring institution based on the signature information of the acquiring application includes step 810.

[0070] Step 810: The security zone program obtains the signature information of the acquiring application and reads the extended fields of the signature information to obtain the identification information of the second sandbox environment corresponding to the target acquiring institution.

[0071] The second sandbox environment refers to isolated data storage areas within the same hardware security zone. Each sandbox environment independently allocates storage resources and sets access permissions. Its purpose is to restrict data interaction between different local acquiring applications and prevent key information from being illegally obtained due to mixed storage.

[0072] As described above, by associating the extended fields in the acquiring application's signature information with the identifier of the second sandbox environment within the hardware security zone, precise location and secure access to the acquiring institution's key are achieved. The security zone program acquires and parses the digital signature of the acquiring application within the protected virtual machine, extracts the identifier information of the target second sandbox environment from its extended fields, and establishes a trusted mapping from the acquiring application to the corresponding key storage space. This method leverages the immutability of digital signatures to ensure the authenticity of the institution's identity and implicitly declares the key storage location through pre-defined extended fields, enabling the security zone program to accurately access the target acquiring institution's exclusive second sandbox environment within the hardware security zone without exposing the specific key path.

[0073] In a specific application scenario, the above-mentioned aggregated payment method is implemented by the aggregated payment system based on the embodiments of this application as follows: The merchant application calls the all-in-one payment processing application interface provided by the general area program. Specifically, the merchant application is a POS system, and the all-in-one payment processing application interface is startPayment(amount, merchantInfo, orderInfo, payMethod), which means that the interface information includes amount - payment amount, merchantInfo - merchant information, orderInfo - order information, and payMethod - payment method.

[0074] The scheduling control module of the normal zone program receives API call requests from merchant applications. Based on the API call requests, it determines the target scheduling mode selected or configured by the merchant, and then forwards the request directly to the corresponding module in the security zone program. Specifically, if the merchant selects background scheduling as the target scheduling mode, the order receiving request is directly forwarded to the background scheduling module of the security zone program; if the merchant selects local scheduling as the target scheduling mode, the order receiving request is directly forwarded to the local scheduling module of the security zone program.

[0075] The pVM management module of the normal zone program loads and runs pVM, and establishes a communication channel with the secure zone program through binder and vSock.

[0076] After the ordinary zone program and the secure zone program establish a communication channel, the ordinary zone program obtains the application package name and application signature information of the merchant application through the system service of the rich execution environment, and encrypts the application package name, application signature information and acquiring request through the first symmetric key in the first storage area of ​​the TEE to obtain the encrypted verification information; and sends the encrypted verification information to the authentication module of the secure zone program.

[0077] The authentication module of the secure zone program decrypts the authentication information using the second symmetric key in the second storage area of ​​the TEE to verify the legitimacy of the caller's identity.

[0078] If the acquiring request is forwarded to the backend scheduling module of the secure zone program, the backend scheduling module converts the acquiring request into a standard interface request for the aggregated acquiring backend and sends it directly to the aggregated acquiring backend via an encrypted channel (such as HTTPS TLS 1.3). This encrypted channel is a network connection between the secure zone program and the aggregated acquiring backend implemented through Micro OS's network services. Upon receiving the standard interface request, the aggregated acquiring backend schedules the corresponding acquiring platform (such as UnionPay, Alipay, or WeChat Pay) to execute the acquiring service based on the merchant and order information. This process can be implemented using existing aggregated payment backend solutions.

[0079] If the acquiring request is forwarded to the local scheduling module of the security zone program, the local scheduling module starts the acquiring application of the target acquiring institution in pVM. The started acquiring application runs in the secure operating system of pVM and establishes a network connection channel with the target acquiring platform corresponding to the target acquiring institution through the network services of the secure operating system. The acquiring application directly calls the acquiring interface of the target acquiring platform to execute acquiring services based on the network connection channel. It can be seen that background scheduling is an independent acquiring platform of the acquiring institution within the security zone program – aggregated acquiring backend; local scheduling is an independent acquiring platform of the acquiring institution within the security zone program – the acquiring application of the acquiring institution; background scheduling and local scheduling generally refer to the strategy selection of the task execution location. With local scheduling, the task is processed wherever it is initiated. With background scheduling, the task is processed in the server background regardless of where it is initiated.

[0080] After completing the acquiring request, the target acquiring platform returns the acquiring result to the aggregate acquiring backend or acquiring application, which then returns the acquiring result to the background scheduling module or local scheduling module of the security zone program.

[0081] The background scheduling module or local scheduling module of the security zone program returns the order collection result to the merchant application through the ordinary zone program, and displays the order collection result in the merchant application.

[0082] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention 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 consolidated payment collection system, characterized in that, Including aggregated payment collection applications; The aggregated acquiring application includes a normal zone program and a secure zone program; The ordinary zone program runs in a rich execution environment, while the secure zone program runs in a protected virtual machine; The protected virtual machine also includes multiple first sandbox environments; Each of the first sandbox environments runs acquiring applications from different acquiring institutions.

2. The aggregated payment system according to claim 1, characterized in that, It also includes a hardware security zone, which comprises multiple secondary sandbox environments; Each of the second sandbox environments stores key information for different acquiring institutions; A connection is established between the first sandbox environment and the second sandbox environment of the same acquiring institution.

3. A method for aggregated payment collection, characterized in that, Applied to an aggregated acquiring system as described in claim 1 or 2, the method includes: The normal zone program receives an acquiring request for the target acquiring institution to perform acquiring services, parses the acquiring request to obtain the target scheduling mode, and loads the protected virtual machine to connect to the secure zone program; If the target scheduling mode is background scheduling, the security zone program executes the acquiring service through the aggregate acquiring background. If the target scheduling mode is local scheduling, the security zone program executes the acquiring service through the acquiring application of the target acquiring institution.

4. The method for aggregated acquiring according to claim 3, characterized in that, The secure zone program executes the acquiring service through the aggregated acquiring backend, including: The security zone program converts the acquiring request into a standard interface request of the aggregated acquiring backend, and the standard interface request includes the institution identifier of the target acquiring institution; The aggregated acquiring backend is invoked based on the standard interface request, instructing the aggregated acquiring backend to invoke the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service according to the institution identifier.

5. The method for aggregated acquiring according to claim 3, characterized in that, The secure zone procedure executes the acquiring service through the acquiring application of the target acquiring institution, including: The secure zone program launches the acquiring application of the target acquiring institution and determines the second sandbox environment corresponding to the target acquiring institution based on the signature information of the acquiring application. The secure zone program reads the target key information of the target acquiring institution from the second sandbox environment, and calls the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service based on the acquiring application and the target key information.

6. The method for aggregated acquiring according to claim 3, characterized in that, After the normal zone program loads the protected virtual machine to connect to the secure zone program, the following is also included: The ordinary zone program obtains the application information of the acquiring request and obtains the first verification key from the first storage area in the hardware security zone. The ordinary zone program encrypts the application information and the acquiring request based on the first verification key to obtain the request ciphertext, and sends the request ciphertext to the secure zone program.

7. The method for aggregated acquiring according to claim 6, characterized in that, Also includes: The secure zone program obtains a second verification key corresponding to the first verification key from the second storage area in the hardware secure zone, and decrypts the request ciphertext based on the second verification key to obtain the application information and the acquiring request, and verifies the legality of the application information; If the application information passes the legality verification, the security zone program executes the acquiring service through the aggregate acquiring backend or the acquiring application of the target acquiring institution. If the validity verification of the application information fails, the security zone program will prohibit the execution of the acquiring service.

8. The method for aggregated acquiring according to claim 4, characterized in that, The secure zone program, based on the standard interface, requests and invokes the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service, including: The secure zone program establishes a first network connection channel with the aggregated acquiring backend through the system network service, and sends the standard interface request to the aggregated acquiring backend in encryption based on the first network connection channel, so as to call the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service through the aggregated acquiring backend.

9. The method for aggregated acquiring according to claim 5, characterized in that, The secure zone program, based on the acquiring application and the target key information, calls the target acquiring platform corresponding to the target acquiring institution to execute the acquiring service, including: The secure zone program establishes a second network connection channel with the target acquiring platform corresponding to the target acquiring institution by calling the system network service through the acquiring application, and directly calls the target acquiring platform to execute the acquiring service based on the second network connection channel and the target key information.

10. The aggregated acquiring method according to claim 5, characterized in that, The security zone procedure determines the second sandbox environment corresponding to the target acquiring institution based on the signature information of the acquiring application, including: The secure zone program obtains the signature information of the acquiring application and reads the extended fields of the signature information to obtain the identification information of the second sandbox environment corresponding to the target acquiring institution.

Images