One-core multi-application electronic payment carrier transaction management method, electronic payment carrier and storage medium

Abstract

According to the one-core multi-application electronic payment carrier transaction management method, the electronic payment carrier and the storage medium provided by the invention, when the preset trigger condition is detected, the priority identifier of the payment application is dynamically adjusted based on the priority switching strategy and persistently stored, so that flexible and dynamic management of the priority of the payment application is realized. Compared with fixed priority setting of a traditional electronic payment carrier, the priority sequence can be adjusted according to actual payment scene requirements, the problem of transaction delay or failure caused by unavailability of a preferred application is effectively avoided, the success rate and response efficiency of payment transaction are improved, and the user payment experience is optimized. Meanwhile, the dynamic priority switching mechanism endows the electronic payment carrier with stronger environmental adaptability, so that the electronic payment carrier can better cope with complex and changeable payment scenes, the diversified requirements of different card organizations, users and payment terminals are met, and technical support is provided for intelligent development of the one-core multi-application electronic payment carrier.

Description

Technical Field

[0001] This application relates to the field of financial payment technology, and in particular to a transaction management method for an electronic payment carrier with multiple applications on a single chip, an electronic payment carrier, and a storage medium. Background Technology

[0002] With the rapid development of electronic payment technology, multi-application electronic payment carriers have become an important tool for improving user payment convenience. However, the priority of each payment application in traditional electronic payment carriers is usually fixed. For example, a certain bank's payment application is set as the highest priority by default, and subsequent transactions will try to launch that application first, regardless of the changing scenario.

[0003] This fixed model has significant limitations in real-world payment scenarios: When a user is using public transportation, if their primary application is their bank card and their transit card has a lower priority, the payment terminal may fail to switch to the transit card before attempting a bank card transaction, increasing transaction processing time. Furthermore, if the primary application becomes unavailable due to network failure or insufficient balance, it may directly cause transaction failure, severely impacting the user's payment experience. In addition, different card organizations and payment terminals have different rules for identifying application priorities, making it difficult for fixed priority settings to adapt to the diverse needs of the payment ecosystem and limiting the scenario coverage of multi-application electronic payment carriers.

[0004] Therefore, how to dynamically adjust the priority of payment applications and improve the scenario adaptability and transaction reliability of electronic payment carriers has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the fact that in the prior art, the payment application priority of electronic payment carriers is fixed and stored after personalization. This not only prolongs the overall transaction response time but also increases the risk of transaction interruption due to the continuous failure of the preferred application in specific scenarios, affecting the transaction success rate and user experience of the payment system. Furthermore, it limits the intelligence and adaptability of cards in complex and ever-changing payment environments.

[0006] This application provides a method for managing electronic payment carrier transactions using a single chip for multiple applications, the method comprising: When a preset trigger condition is detected, a switching operation is performed on the priority identifiers of at least two payment applications currently stored in this carrier, according to a preset priority switching strategy. The priority identifier after the switch will be persistently stored; The priority identifier of the persistent storage is used to determine the payment application that will be used preferentially in the current or next payment transaction.

[0007] Optionally, the electronic payment carrier includes software payment applications and hardware payment carriers; When the electronic payment carrier is a software payment application, the preset triggering conditions include at least one of the following: detecting the successful completion of a contactless transaction, the count value of the transaction counter related to the software payment application reaching a preset threshold, and reaching a preset time period node; When the electronic payment carrier is a hardware payment carrier, the preset triggering conditions include at least one of the following: receiving a near-field payment system environment selection command from the payment terminal, detecting the successful completion of a contactless transaction, the count value of the transaction counter associated with the hardware payment carrier reaching a preset threshold, and reaching a preset time period node.

[0008] Optionally, when the electronic payment carrier is a hardware payment carrier, and the preset triggering condition is receiving a near-field payment system environment selection command sent by the payment terminal, after persistently storing the switched priority identifier, the method further includes: In response to a proximity payment system environment selection command issued by the payment terminal in the current or next contactless payment transaction, the switched priority identifier is organized into response data and returned to the payment terminal, so that the payment terminal can select the target payment application for the transaction based on the response data.

[0009] Optionally, the step of performing a priority switching operation on the priority identifiers of at least two payment applications currently stored in this carrier according to a preset priority switching strategy includes: Read the priority identifiers of at least two payment applications currently stored in this carrier; The priority identifiers of each payment application are swapped to enable the switching operation.

[0010] Optionally, when there are two payment applications, exchanging the priority identifiers of the various payment applications includes: The priority identifiers of the two payment applications are swapped.

[0011] Optionally, when there are three or more payment applications, exchanging the priority identifiers of the various payment applications includes: The priority identifiers of each payment application are rearranged according to a preset rotation sequence to exchange the priority identifiers of each payment application. The preset rotation sequence is determined based on a preset permutation algorithm.

[0012] Optionally, the step of performing a priority switching operation on the priority identifiers of at least two payment applications currently stored in this carrier according to a preset priority switching strategy includes: Retrieve pre-stored lists of applications with different priority orders and their corresponding activation states; Based on the activation status of each group of application lists, select one group of application lists as the target list. Based on the target list, a priority switching operation is performed on the priority identifiers of at least two payment applications currently stored in this carrier.

[0013] Optionally, the step of persistently storing the switched priority identifier includes: The switched priority identifier is written into the non-volatile memory of the electronic payment carrier or into the terminal device that carries the electronic payment carrier.

[0014] This application also provides an electronic payment carrier, which includes a security chip configured to perform the steps of the one-chip-multiple-application electronic payment carrier transaction management method as described in any of the above embodiments.

[0015] This application also provides a computer-readable storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the one-chip-multiple-application electronic payment carrier transaction management method as described in any of the above embodiments.

[0016] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: This application provides a transaction management method, electronic payment carrier, and storage medium for a single-chip multi-application electronic payment carrier. By dynamically adjusting and persistently storing the priority identifier of the payment application based on a priority switching strategy when a preset trigger condition is detected, this application achieves flexible and dynamic management of payment application priorities. Compared to the fixed priority settings of traditional electronic payment carriers, this application can adjust the priority order according to the actual payment scenario requirements, effectively avoiding transaction delays or failures caused by the unavailability of the preferred application, improving the success rate and response efficiency of payment transactions, and optimizing the user payment experience. Simultaneously, the dynamic priority switching mechanism gives the electronic payment carrier stronger environmental adaptability, enabling it to better cope with complex and ever-changing payment scenarios and meet the diverse needs of different card organizations, users, and payment terminals, providing technical support for the intelligent development of single-chip multi-application electronic payment carriers. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a method for managing electronic payment carrier transactions using a single chip with multiple applications, provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating one method of performing a switching operation according to an embodiment of this application. Figure 3 This is a schematic diagram illustrating another process for performing a switching operation, provided in an embodiment of this application. Figure 4 This is a schematic diagram of the structure of a financial IC card provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] Against the backdrop of the rapid development of electronic payment technology, multi-application electronic payment carriers have become an important means of enhancing user payment convenience. In this application, multi-application electronic payment carriers can be divided into two categories: hardware payment carriers, such as physical devices like financial IC cards, SIM cards, and smart bracelets that integrate multiple payment applications; and software payment applications, such as digital wallets and payment apps installed on smartphones, tablets, and other terminals. Whether hardware carriers or software applications, the core requirement is to achieve flexible switching and priority management of different payment applications to adapt to diverse payment scenarios and user habits.

[0021] Furthermore, the payment applications within different carriers in this application also exhibit certain differences. For hardware payment carriers, the payment applications are typically stored in the non-volatile memory of the chip in the form of mini-programs or embedded applications, such as the UnionPay application and VISA application within a financial IC card. Each application has independent transaction logic and security domains, and is scheduled and managed through the chip operating system (COS). Software payment applications, on the other hand, run in the operating system environment of the terminal device as code modules, such as the bank card payment module and third-party payment module integrated within a digital wallet APP. Each module interacts with the terminal hardware and payment system through application programming interfaces (APIs), and its storage and operation depend on the terminal's memory and storage resources.

[0022] This application will specifically illustrate the electronic payment carrier transaction management method of this application through the following embodiments, as follows: In one embodiment, such as Figure 1 As shown, Figure 1 A flowchart illustrating a transaction management method for a single-chip, multi-application electronic payment carrier provided in this application embodiment; this application provides a transaction management method for a single-chip, multi-application electronic payment carrier, the method including: S110: When a preset trigger condition is detected, a switching operation is performed on the priority identifiers of at least two payment applications currently stored in this carrier according to a preset priority switching strategy.

[0023] In this step, the electronic payment carrier can monitor various system events and external interaction commands in real time to determine whether to trigger priority switching logic. The triggering conditions preset in this application refer to specific scenarios or events that can induce priority switching operations. Their design can be set according to the real-time requirements of the payment scenario and the rational utilization of card resources, and is not limited here.

[0024] For example, when the electronic payment carrier is a hardware payment carrier, if a near-field payment system environment selection command sent by the payment terminal is detected, the priority switching logic can be triggered immediately; if it is a software payment application, the switching operation can be automatically executed when a contactless transaction is successfully completed, or when the transaction counter value accumulates to a preset threshold (such as 5 consecutive transactions).

[0025] The preset priority switching strategy is a priority adjustment rule pre-configured based on different scenario requirements. Its core is to dynamically adjust the application priority to adapt to the actual needs of the current payment scenario. For example, in a public transportation scenario, when a transportation payment instruction sent by the terminal is detected, the switching strategy can automatically raise the priority of the transportation card application to the highest level, ensuring that the transaction is completed first through the transportation card. In a supermarket or shopping mall scenario, if a large payment instruction is detected, the priority of the bank card application can be adjusted to the top, satisfying the user's preference for large-amount payment tools.

[0026] The priority switching strategy can also be configured according to the number of payment applications and actual business needs. For example, if the electronic payment carrier only has two built-in payment applications (such as UnionPay and Visa applications), the strategy can be set to the "fixed swap" mode, that is, directly swap the priority identifiers of the two applications. For example, the UnionPay application identifier with the original priority of "1" is switched to "2", and the Visa application identifier with the original priority of "2" is switched to "1". If three or more payment applications are built-in (such as UnionPay, Visa and Mastercard applications are included at the same time), the strategy can adopt the rotation mode, which generates a fixed rotation sequence based on the preset replacement algorithm (such as UnionPay → Visa → Mastercard → UnionPay). Each time the switch is performed, the application with the highest current priority is rotated to the last position, and the priority of the other applications is increased by one position in turn. For example, the initial priority is UnionPay (1), Visa (2), Mastercard (3), and after the switch it becomes Visa (1), Mastercard (2), UnionPay (3), ensuring that all applications have the opportunity to obtain the highest priority.

[0027] In addition, this application also supports the "scenario-based preset list switching" strategy: the electronic payment carrier can pre-store multiple application lists with different priority orders (such as setting UnionPay as the highest priority in the "domestic priority list" and Visa as the highest priority in the "overseas priority list"), and configure an activation status identifier for each list. When the geographical location information or transaction type instruction sent by the terminal is detected, the list with the corresponding activation status is automatically selected as the target list, and the priority identifiers of all payment applications are updated in batches.

[0028] S120: Persistently store the priority identifier after the switch.

[0029] In this step, after the priority identifiers of at least two payment applications currently stored in this carrier are switched according to the preset priority switching strategy by S110, the electronic payment carrier can also persistently store the adjusted priority identifiers to ensure that the priority settings are maintained even after the card is powered off.

[0030] Furthermore, the priority identifier in the persistent storage of this application is used to determine the payment application that will be used preferentially in the current or next payment transaction. For example, when a payment terminal initiates a contactless transaction request, the chip operating system (COS) of the electronic payment carrier will first read the priority identifier in the persistent storage and call the corresponding payment application in descending order to initialize the transaction. If the application with the highest priority cannot complete the transaction due to reasons such as terminal incompatibility, insufficient balance, or security verification failure, the COS will automatically downgrade and call the application with the next lower priority until the transaction is successful or all applications have been tried. Taking a smart bracelet that integrates three applications, UnionPay, Visa, and transit card, as an example, assuming that the current priority identifier in the persistent storage is transit card (1), UnionPay (2), and Visa (3), when the user swipes their card at a bus terminal, the bracelet will prioritize launching the transit card application to complete the transaction; if the user uses it in a supermarket abroad, and the transit card application is not supported by the terminal, the COS will automatically switch to the UnionPay application, and if UnionPay is still unavailable, it will try the Visa application, effectively avoiding transaction failure due to the failure of a single application. In addition, the persistent storage priority identifier also supports consistency across terminal scenarios. For example, after a user triggers a priority switch on terminal A, the switched identifier will be written into the chip's Flash memory. The next time a transaction is made on terminal B, terminal B will still read the latest priority setting, ensuring that the user's priority preference remains consistent in different payment scenarios without repeated adjustments.

[0031] In the above embodiments, by dynamically adjusting and persistently storing the priority identifier of the payment application based on a priority switching strategy when a preset trigger condition is detected, flexible and dynamic management of the payment application priority is achieved. Compared with the fixed priority settings of traditional electronic payment carriers, this application can adjust the priority order according to the actual payment scenario requirements, effectively avoiding transaction delays or failures caused by the unavailability of the preferred application, improving the success rate and response efficiency of payment transactions, and optimizing the user payment experience. At the same time, the dynamic priority switching mechanism gives the electronic payment carrier stronger environmental adaptability, enabling it to better cope with complex and ever-changing payment scenarios and meet the diverse needs of different card organizations, users, and payment terminals, providing technical support for the intelligent development of multi-application electronic payment carriers.

[0032] In one embodiment, the electronic payment carrier may include a software payment application and a hardware payment carrier.

[0033] When the electronic payment carrier is a software payment application, the preset triggering conditions include at least one of the following: detecting the successful completion of a contactless transaction, the count value of the transaction counter related to the software payment application reaching a preset threshold, and reaching a preset time period node.

[0034] When the electronic payment carrier is a hardware payment carrier, the preset triggering conditions include at least one of the following: receiving a near-field payment system environment selection command from the payment terminal, detecting the successful completion of a contactless transaction, the count value of the transaction counter associated with the hardware payment carrier reaching a preset threshold, and reaching a preset time period node.

[0035] In this embodiment, the design of preset trigger conditions for different types of electronic payment carriers further refines the scenario adaptability, ensuring that the priority switching logic can accurately match the operating characteristics of the hardware and software carriers.

[0036] Taking software payment applications as an example, if a contactless transaction is successfully completed, such as when a user uses their mobile phone's NFC to swipe their card at a subway gate, the system can automatically trigger a priority switch, temporarily prioritizing frequently used transportation payment applications to adapt to similar scenarios in the future. The transaction counter trigger focuses more on the regularity of user behavior—for example, when a user completes three small-amount food and beverage payments consecutively using their digital wallet, the counter reaches a preset threshold, and the system can prioritize frequently used third-party payment applications, reducing repetitive selection. The preset time period trigger method is suitable for scenarios where users' payment habits exhibit clear time-based characteristics, such as automatically setting transportation card applications to the highest priority during weekday morning rush hour (7:00-9:00) and switching to commonly used bank card applications in supermarkets and shopping malls after the evening rush hour, achieving intelligent scheduling based on the time dimension.

[0037] For hardware payment carriers, in addition to the transaction completion, counter threshold, and time period triggering conditions similar to those for software carriers, a hardware-specific triggering scenario is added: "receiving a near-field payment system environment selection command from the payment terminal." For example, when a user brings a multi-application integrated financial IC card close to a POS terminal supporting UnionPay QuickPass, the terminal sends a selection command containing its own list of supported applications. If the IC card detects that the command includes a support identifier for the VISA application, and the current VISA application has a low priority, the system can immediately trigger a switching strategy to prioritize the VISA application, ensuring that the terminal identifies and calls that application to complete the transaction. This triggering method, based on proactive terminal interaction, can quickly respond to the environmental needs of the payment terminal, avoiding transaction initialization failures caused by mismatches between application priority and terminal support range, further improving the compatibility of the hardware carrier in different terminal environments.

[0038] Furthermore, the triggering conditions mentioned above in this application can be configured individually or used in combination. For example, a hardware payment carrier can simultaneously enable the "transaction counter threshold" and "terminal environment selection command" triggering conditions: when a user completes four consecutive transactions (below the five-transaction threshold), if a VISA support command is received from an overseas POS terminal, the system can immediately trigger priority switching without waiting for the counter to reach the threshold. Software payment applications can combine the "time period node" and "transaction completion" triggering conditions. For instance, during weekday morning rush hours, after a user completes their first transportation card transaction, the system automatically locks the transportation card priority to the highest level until the morning rush hour ends, avoiding frequent switching that could affect payment efficiency. This combined triggering mechanism can balance the real-time nature of the scenario with the regularity of user behavior, making priority switching more aligned with actual payment needs.

[0039] In one embodiment, when the electronic payment carrier is a hardware payment carrier, and the preset trigger condition is receiving a near-field payment system environment selection command sent by the payment terminal, the step of persistently storing the switched priority identifier may further include: S130: In response to a proximity payment system environment selection command issued by the payment terminal in the current or next contactless payment transaction, the switched priority identifier is organized into response data and returned to the payment terminal, so that the payment terminal selects the target payment application for the transaction based on the response data.

[0040] In this embodiment, when the electronic payment carrier is a hardware payment carrier, and the carrier detects the near-field payment system environment selection command triggered by the payment terminal, it automatically enters the response data construction process after completing the persistent storage of the priority identifier.

[0041] In this process, the carrier can first read the latest priority identifier from the non-volatile memory, and combine the priority identifier with the AID (application identifier) ​​and application name of the payment application according to the protocol format supported by the payment terminal to generate a response message containing the application list and priority order.

[0042] For example, the switched Visa priority identifier "01" is combined with AID "a0000000031010" and the application name "Visa," while the UnionPay priority identifier "02" is combined with AID "a0000000032010" and the application name "UnionPay." The system arranges this information in descending order of priority and encapsulates it into TPDU (Transmission Protocol Data Unit) format response data. Subsequently, this carrier sends the response data to the payment terminal through its contactless interface. After receiving the data, the terminal parses out the Visa application with the highest priority and directly initiates a transaction request for that application, without having to try the original higher-priority UnionPay application, thereby shortening the transaction response time and improving payment efficiency.

[0043] In one embodiment, such as Figure 2 As shown, Figure 2 This is a schematic diagram illustrating one method of performing a switching operation according to an embodiment of this application; S110, according to a preset priority switching strategy, performs a switching operation on the priority identifiers of at least two payment applications currently stored in this carrier, which may include: S111: Read the priority identifiers of at least two payment applications currently stored in this carrier.

[0044] S112: Exchange the priority identifiers of each payment application to achieve the switching operation.

[0045] In this embodiment, when performing a switching operation on the priority identifiers of at least two payment applications currently stored in this carrier, the adjustment can be completed by directly exchanging the values ​​of the priority identifiers.

[0046] For example, when an electronic payment carrier integrates a UnionPay application (original priority identifier "1") and a Visa application (original priority identifier "2"), the carrier first reads the current priority identifiers of these two applications, and then executes the exchange logic: updating the priority identifier of the UnionPay application to "2" and the priority identifier of the Visa application to "1", thus completing the priority swap. This "fixed swap" strategy is suitable for scenarios containing only two payment applications. Its operation logic is simple and efficient, requiring no complex algorithms, and can quickly achieve dynamic priority adjustment.

[0047] If an electronic payment device has three built-in payment applications (such as UnionPay, Visa, and Mastercard, with original priority identifiers of "1", "2", and "3" respectively), after reading the current identifier, the device can perform an exchange according to a preset rotation rule: the highest priority UnionPay identifier "1" is adjusted to "3", Visa's "2" is adjusted to "1", and Mastercard's "3" is adjusted to "2", forming a cyclical rotation sequence of "UnionPay → Visa → Mastercard → UnionPay". This identifier exchange based on preset rules ensures the regularity of priority adjustment and balances the usage opportunities of different applications, preventing a single application from occupying a priority position for a long time.

[0048] When the electronic payment carrier is a software payment application, its priority identifier exchange logic can be dynamically optimized based on user behavior data. For example, a software payment application may have three built-in applications: Alipay, WeChat Pay, and Cloud Pay, with original priority identifiers of "1", "2", and "3" respectively. When it is detected that a user's WeChat Pay usage frequency has reached 60% of the total number of payments within the past week (exceeding the preset 50% threshold), and the trigger condition is "transaction counter count reaches 10 transactions", the carrier reads the current priority identifier and executes the "high-frequency application priority" exchange strategy: adjusting the priority identifier of WeChat Pay from "2" to "1", adjusting Alipay's original priority of "1" to "2", and keeping Cloud Pay unchanged at "3". This dynamic exchange based on usage frequency can more accurately match the user's actual payment preferences and improve the calling efficiency of high-frequency applications.

[0049] In addition, electronic payment carriers also support conditional exchange based on application attributes. For example, they can read the transaction success rate data of an application. If an application fails to complete three transactions in a row, the system will automatically exchange its priority flag with the application with the highest success rate, ensuring that the more stable payment application is used first and improving transaction reliability.

[0050] In one embodiment, when there are two payment applications, the priority identifiers of the various payment applications are exchanged in step S112, which may include: The priority identifiers of the two payment applications are swapped.

[0051] In this embodiment, when there are two payment applications, the priority identifier exchange logic can be simplified to a direct swap operation. This operation does not require the introduction of complex rotation algorithms or condition judgments, and can complete the priority adjustment with extremely low computational resource consumption.

[0052] Specifically, the electronic payment device first reads the current priority identifier values ​​of two payment applications through internal registers. For example, application A's identifier is "0x01" (representing the highest priority), and application B's identifier is "0x02" (representing the second highest priority). Subsequently, the system calls a memory swap instruction to update application A's identifier to "0x02" and application B's identifier to "0x01," completing a single swap. The execution time of this swap operation can be controlled at the microsecond level, without affecting the terminal's transaction response speed.

[0053] This optimized design for dual application scenarios ensures flexibility in priority adjustment, simplifies system logic, and reduces the development complexity and maintenance cost of card firmware.

[0054] In one embodiment, when there are three or more payment applications, the priority identifiers of the various payment applications are exchanged in step S112, which may include: The priority identifiers of each payment application are rearranged according to a preset rotation sequence to exchange the priority identifiers of each payment application.

[0055] The preset rotation sequence is determined based on a preset permutation algorithm.

[0056] In this embodiment, when there are three or more payment applications, the priority identifiers of each payment application can be rearranged according to a preset rotation sequence to exchange the priority identifiers of each payment application. The preset rotation sequence can be determined based on a preset permutation algorithm, such as by a pseudo-random algorithm (e.g., a linear congruential algorithm) or a deterministic rotation algorithm (e.g., a circular left shift algorithm).

[0057] For example, when using a cyclic left-shift algorithm, if the initial payment application sequence is UnionPay (identifier 1), Visa (identifier 2), Mastercard (identifier 3), and JCB (identifier 4), the preset rotation sequence can be set to "UnionPay → Visa → Mastercard → JCB → UnionPay". Each time a switch occurs, the application with the highest current priority is moved to the end of the sequence, and the remaining applications are shifted one position to the left in sequence: after the switch, Visa becomes identifier 1, Mastercard becomes identifier 2, JCB becomes identifier 3, and UnionPay becomes identifier 4. If a pseudo-random algorithm is used, the system can generate a fixed-length rotation sequence based on the card's unique serial number as a seed. For example, if the seed is "12345678", the generated sequence would be "Visa → JCB → UnionPay → Mastercard → Visa", ensuring that the priority order of each switch is predictable and without repetition or omission.

[0058] Furthermore, the preset rotation sequence supports dynamic updates. The electronic payment carrier can receive new permutation algorithm parameters sent by the issuing bank via secure messages. For example, the original circular left-shift algorithm can be adjusted to a circular right-shift algorithm, or the seed value of the pseudo-random algorithm can be updated, so that the rotation sequence adapts to new business needs. For instance, when a user frequently travels to a certain location recently, the issuing bank can send parameters to add the local application to the priority rotation queue, generating a sequence of "local application identifier → UnionPay → Visa → Mastercard → local application identifier", thereby improving the adaptability of payment transactions.

[0059] This multi-application priority adjustment based on a preset rotation sequence not only ensures the regularity of priority switching, but also meets the needs of personalized scenarios through dynamic configuration of algorithm parameters, achieving a balance between flexibility and stability.

[0060] In one embodiment, such as Figure 3 As shown, Figure 3 This is a schematic diagram illustrating another process for performing a switching operation provided in an embodiment of this application; S110, according to a preset priority switching strategy, performs a switching operation on the priority identifiers of at least two payment applications currently stored in this carrier, which may include: S210: Retrieve multiple pre-stored lists of applications with different priority orders and their corresponding activation states.

[0061] S211: Based on the activation status of each group of application lists, select one group of application lists as the target list.

[0062] S212: Perform a switching operation on the priority identifiers of at least two payment applications currently stored in this carrier according to the target list.

[0063] In this embodiment, the electronic payment carrier can pre-store multiple application lists with different priority rankings (such as setting UnionPay as the highest priority in the "domestic priority list" and Visa as the highest priority in the "overseas priority list"), and configure an activation status identifier for each list. When the geographical location information or transaction type instruction sent by the terminal is detected, the list with the corresponding activation status is automatically selected as the target list, and the priority identifiers of all payment applications are updated in batches.

[0064] Specifically, when the electronic payment carrier of this application is a hardware payment carrier, this application can pre-divide an independent list storage area within the non-volatile storage area of ​​the electronic payment carrier to store multiple application lists with different priority orders. Each list corresponds to a unique list identifier and an activation status bit (e.g., "0" represents inactive, "1" represents active). For example, for cross-border business users, three lists can be pre-stored: List 1 (identifier L1, activation status 1) is adapted for domestic scenarios, with a priority order of UnionPay → Visa → Mastercard; List 2 (identifier L2, activation status 0) is adapted for overseas scenarios, with a priority order of Visa → Mastercard → UnionPay; List 3 (identifier L3, activation status 0) is adapted for duty-free shop scenarios, with a priority order of JCB → UnionPay → Visa. In each list, the priority identifier of each payment application is bound to its AID and application attributes (such as supported transaction types and applicable regions) to form structured data.

[0065] When a preset trigger condition is detected, the electronic payment device first reads the activation status bits of all application lists in the list storage area and filters out the target list with an activation status of "1". For example, if the user is currently overseas, and the issuing bank updates the activation status bit of list 2 from "0" to "1" via remote management commands, the system will automatically select list 2 as the target list upon triggering. Subsequently, the system parses the priority sorting rules in the target list and replaces the priority identifiers of each payment application currently stored with the corresponding identifier values ​​in the target list. Taking list 2 as an example, the original priority identifier for UnionPay was "01", Visa was "02", and Mastercard was "03". After replacement, the UnionPay identifier is updated to "03", Visa is updated to "01", and Mastercard is updated to "02", completing the priority switch.

[0066] When the electronic payment carrier of this application is a software payment application, its pre-stored multiple application lists can be integrated into an encrypted partition of the local storage module, and users can manually configure the list content and activation status through the application's settings interface. For example, the software payment application has three preset lists: "Daily Consumption List," "Large Amount Transfer List," and "Cross-border Payment List." Users can adjust the priority order of each list according to their own needs: setting the priority of the "Daily Consumption List" to WeChat Pay → Alipay → UnionPay, and the "Large Amount Transfer List" to UnionPay → Alipay → WeChat Pay, and switching the activation status by clicking the "Activate" button next to the list. When the trigger condition is "a transaction amount exceeding 5,000 yuan is detected", the system automatically reads the activation status of all lists, selects the "large transfer list" with an activation status of "1" as the target list, and updates the priority identifier of the current payment application in batches to the corresponding value in the list - the original WeChat Pay priority identifier "01" is updated to "03", Alipay "02" is updated to "02", and UnionPay "03" is updated to "01", ensuring that large transactions prioritize the use of UnionPay QuickPass application that supports higher transfer limits, thereby improving transaction security and compatibility.

[0067] Furthermore, the software payment application also supports user-defined new lists. For example, users can create a "Travel Scenario List," prioritizing subway app payments → bus card payments → Alipay travel code payments, and setting the trigger condition to "connect to a specified subway Wi-Fi." When the system detects the Wi-Fi signal, it automatically activates the list, completing the priority switch. This switching method based on pre-stored multiple lists eliminates the need to adjust the priority identifiers of individual applications one by one, significantly reducing switching time. Simultaneously, through dynamic control of activation status, it achieves rapid adaptation of payment application priorities in different scenarios, further enhancing the scenario-based intelligent response capabilities of electronic payment carriers.

[0068] Furthermore, the activation status of multiple application lists in this application can be automatically switched through preset rules. For example, the system can have a built-in geolocation recognition module (determined by the region code reported by the terminal). When the terminal region code is detected to be "US" (United States), the system automatically sets the activation status bit of list 2 to "1" and sets the activation status bit of other lists to "0". When the region code is switched to "CN" (China), list 1 is automatically activated again.

[0069] This scenario-based automatic activation mechanism allows payment application priority adjustments to better align with actual user needs, eliminating the need for manual user intervention. Furthermore, the system supports updating pre-stored lists via extended commands from the payment terminal. For example, the terminal can send an "update list" command carrying new priority sorting data. After the electronic payment carrier verifies the command's validity, the new list is written to storage and the activation status is updated, further enhancing the flexibility of list management.

[0070] In one embodiment, persistently storing the switched priority identifier in S120 may include: S121: Write the switched priority identifier into the non-volatile memory of the electronic payment carrier, or into the terminal device that loads the electronic payment carrier.

[0071] In this embodiment, for the hardware payment carrier, the non-volatile memory (such as EEPROM or Flash) of the hardware payment carrier provides a stable storage medium for the priority identifier. It has the characteristic of not losing data when power is off, which can ensure that the priority state after the switch is still maintained after the card is powered off. Before performing persistent storage, the system can first perform integrity verification on the priority identifier after the switch. For example, it can generate a check code for the identifier data through the CRC (Cyclic Redundancy Check) algorithm and compare it with a preset check value. If they match, the writing process is initiated to avoid invalid or erroneous data being stored.

[0072] The writing process can be performed in a step-by-step manner: For a designated storage block of non-volatile memory (this block is pre-divided for storing priority identifiers and mapped to the payment application's AID storage block), the system first sends an erase command to clear the original data in the block, and then writes the switched identifier to the corresponding address sequentially according to the key-value pair format of "application AID + priority identifier". For example, the UnionPay application's AID "a0000000032010" corresponds to storage address 0x0010, and the switched priority identifier "03" will be written to this address; the Visa application's AID "a0000000031010" corresponds to address 0x0020, and the identifier "01" will be written to this address.

[0073] After the write operation is complete, the system can perform a read-back verification: reread the priority identifier data in the storage block and compare it byte by byte with the target data after the switch. If they are completely consistent, an internal status code of "storage successful" is returned. If there are differences, a retry mechanism is triggered (up to 3 retries). If the retry fails, an error log is recorded and the original priority identifier is maintained to ensure the reliability of the storage operation. In addition, the write operation of non-volatile memory can be restricted to low-power mode, and the amount of data written at one time is controlled within 128 bytes to reduce the dependence on the card battery (if it is an active card) or terminal power supply and extend the card's lifespan.

[0074] For software payment applications, persistent storage can be achieved using the local encrypted storage module of the terminal device. When a software payment application is installed on the terminal, it can request an independent encrypted storage directory from the system. This directory is only accessible to the application itself, and data transmission is protected by encryption algorithms. After the priority identifier switch is completed, the system first associates the switched identifier data with the application's unique identifier (such as the application package name + user ID) to generate structured JSON data. Then, it performs a hash operation on this JSON data to generate a digest value, which is written along with the data to the relevant file in the encrypted storage directory.

[0075] After the write operation is complete, the software payment application can initiate a data consistency check: read the digest value in the file, re-hash the identifier data in the file and compare it. If they match, the storage is confirmed to be successful; if they do not match, the file is determined to be corrupted. The application will immediately read the most recent valid configuration file from the backup directory (an encrypted backup area created in advance on the terminal SD card or cloud storage) for recovery and send a notification to the user that "configuration storage is abnormal and has been restored to the latest version".

[0076] Whether it's a hardware payment platform or a software payment application, the priority identifier data in persistent storage can be quickly read by subsequent transaction processes: when a terminal initiates a payment request, the system can read the priority identifier from non-volatile memory or an encrypted storage directory within microseconds, and call the corresponding payment application according to the identifier order, ensuring the efficiency of the transaction process. Simultaneously, the priority identifier in persistent storage serves as the basis for subsequent priority switching strategies—before executing the next switching operation, the system will first read the current stored identifier state, and combine it with new triggering conditions (such as the number of failed transactions or changes in the scenario) to generate a new priority sequence, achieving continuity and dynamism in priority adjustment.

[0077] In one embodiment, this application also provides an electronic payment carrier including a security chip configured to perform the steps of the one-chip-multiple-application electronic payment carrier transaction management method as described in any of the above embodiments.

[0078] In this embodiment, as Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of a financial IC card provided in an embodiment of this application; Figure 4Taking a financial IC card as an example, the security chip within the card integrates core components such as a near-field payment system environment dynamic management module and non-volatile memory (e.g., EEPROM or Flash). The near-field payment system environment dynamic management module includes a state memory, a trigger condition detector, and priority exchange logic; the non-volatile memory persistently stores key information such as the payment application's AID, priority identifier, pre-stored application list, and activation status.

[0079] Specifically, when a user initiates a transaction at a payment terminal, the security chip first establishes communication with the terminal via a contactless interface and receives the application selection command sent by the terminal. Upon responding to the command, the security chip reads the priority identifiers of all payment applications from non-volatile memory (or, if a switching operation has been performed previously, the switched identifiers from persistent storage), and generates an application priority list in descending order of identifiers. The terminal then attempts to select applications sequentially based on this list, prioritizing the application with the lowest identifier value to initiate the transaction. For example, if the priority identifier for the Visa application after the switch is "01" and for UnionPay it is "03," the terminal will prioritize the Visa application to complete the transaction, achieving automatic application selection based on priority.

[0080] Furthermore, the security chip supports remote interaction with the issuing bank, receiving update instructions for priority switching strategies via a secure message channel. For example, the issuing bank can issue new permutation algorithm parameters (such as adjusting the circular left shift algorithm to a dynamic sorting algorithm based on transaction frequency). After the security chip verifies the signature validity of the instruction, it updates the algorithm parameters stored in the non-volatile memory and executes the new strategy the next time a priority switch is triggered. This collaborative design of hardware and software logic enables electronic payment carriers to flexibly adapt to payment needs in different scenarios, improving transaction efficiency and user experience.

[0081] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic payment carrier to which the present application is applied. A specific electronic payment carrier may include more or fewer modules than those shown in the figure, or may combine certain modules, or may have different module arrangements.

[0082] In one embodiment, this application also provides a computer-readable storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the one-chip-multiple-application electronic payment carrier transaction management method as described in any of the above embodiments.

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

[0084] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0085] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for managing transactions on a single-chip, multi-application electronic payment carrier, characterized in that: The method includes: When a preset trigger condition is detected, a switching operation is performed on the priority identifiers of at least two payment applications currently stored in this carrier, according to a preset priority switching strategy. The priority identifier after the switch will be persistently stored; The priority identifier of the persistent storage is used to determine the payment application that will be used preferentially in the current or next payment transaction.

2. The method according to claim 1, characterized in that, The electronic payment carrier includes software payment applications and hardware payment carriers; When the electronic payment carrier is a software payment application, the preset triggering conditions include at least one of the following: detecting the successful completion of a contactless transaction, the count value of the transaction counter related to the software payment application reaching a preset threshold, and reaching a preset time period node; When the electronic payment carrier is a hardware payment carrier, the preset triggering conditions include at least one of the following: receiving a near-field payment system environment selection command from the payment terminal, detecting the successful completion of a contactless transaction, the count value of the transaction counter associated with the hardware payment carrier reaching a preset threshold, and reaching a preset time period node.

3. The method according to claim 1, characterized in that, When the electronic payment carrier is a hardware payment carrier, and the preset trigger condition is receiving a near-field payment system environment selection command sent by the payment terminal, after persistently storing the switched priority identifier, the method further includes: In response to a proximity payment system environment selection command issued by the payment terminal in the current or next contactless payment transaction, the switched priority identifier is organized into response data and returned to the payment terminal, so that the payment terminal can select the target payment application for the transaction based on the response data.

4. The method according to claim 1, characterized in that, The step of performing a priority switching operation on the priority identifiers of at least two payment applications currently stored in this carrier according to a preset priority switching strategy includes: Read the priority identifiers of at least two payment applications currently stored in this carrier; The priority identifiers of each payment application are swapped to enable the switching operation.

5. The method according to claim 4, characterized in that, When there are two payment applications, the step of exchanging the priority identifiers of the various payment applications includes: The priority identifiers of the two payment applications are swapped.

6. The method according to claim 4, characterized in that, When there are three or more payment applications, the step of exchanging the priority identifiers of the various payment applications includes: The priority identifiers of each payment application are rearranged according to a preset rotation sequence to exchange the priority identifiers of each payment application. The preset rotation sequence is determined based on a preset permutation algorithm.

7. The method according to claim 1, characterized in that, The step of performing a priority switching operation on the priority identifiers of at least two payment applications currently stored in this carrier according to a preset priority switching strategy includes: Retrieve pre-stored lists of applications with different priority orders and their corresponding activation states; Based on the activation status of each group of application lists, select one group of application lists as the target list. Based on the target list, a priority switching operation is performed on the priority identifiers of at least two payment applications currently stored in this carrier.

8. The method according to any one of claims 1-7, characterized in that, The step of persistently storing the switched priority identifier includes: The switched priority identifier is written into the non-volatile memory of the electronic payment carrier or into the terminal device that carries the electronic payment carrier.

9. An electronic payment carrier, characterized in that, The electronic payment carrier includes a security chip configured to perform the steps of the one-chip-multiple-application electronic payment carrier transaction management method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the one-chip-multi-application electronic payment carrier transaction management method as described in any one of claims 1 to 8.

Images