CN115564417A - Electronic payment method, electronic device, storage medium, and computer program product - Google Patents

Abstract

The application relates to the technical field of intelligent terminals, in particular to an electronic payment method, electronic equipment, a storage medium and a computer program product, wherein a plurality of payment applications and payment management applications are installed on the electronic equipment, and the method comprises the following steps: the payment management application detects a first payment operation of a user in the payment management application, wherein the first payment operation indicates that a payment function is completed by adopting a first payment application in the plurality of payment applications; the payment management application calls the payment function of the first payment application to complete the payment function corresponding to the first payment operation. According to the payment management method and the payment management system, the payment management application is arranged to manage the plurality of payment applications installed on the electronic equipment, the payment capability module providing the payment function in each payment application exists in an independent atomic capability module form in the distributed operating system carried by the electronic equipment, and the payment management application completes payment by calling the payment capability module, so that the payment behaviors of a user are managed in a unified mode.

Description

Electronic payment method, electronic device, storage medium and computer program product

technical field

The present invention relates to the technical field of intelligent terminals, in particular to an electronic payment method, electronic equipment, a storage medium and a computer program product.

Background technique

With the development of smart terminals and Internet technology, mobile payment has gradually become the mainstream payment method for people. Nowadays, in many payment scenarios, users can not only use various terminal devices for payment behaviors, such as mobile phones, watches, bracelets, etc., but also choose payment channels arbitrarily, such as through ^AlipayTM , ^WeChatTM , UnionPay Cloud ^QuickPassTM , Bank clients and other payment channels complete the payment, and the above-mentioned payment channels are respectively provided by payment applications with payment functions such as ^AlipayTM , ^WeChatTM , UnionPay Cloud ^QuickPassTM and bank clients.

It can be understood that when a user performs a payment operation in an offline scenario, the general user will open the payment application on the terminal device to show the payment code to the merchant for payment, or open the payment application on the terminal device to scan the payment collection code provided by the merchant to make payment ; and when the middle-end users in the online scene need to perform payment operations, such as in the online shopping scene, after the general user selects the product, if the shopping application that the user performs the payment operation itself has a payment function, such as Meituan ^TM , the user can click to pay After selecting the option, enter the payment password or fingerprint verification to complete the payment; if the shopping application where the user performs the payment operation does not have the payment function, the user will jump to the third-party payment application to complete the payment after clicking the payment ^option . When you click on the payment option when shopping online, you can choose to jump to Alipay ^TM for payment.

In the above payment operation process, no matter which payment application the user uses to complete the payment, each payment application can only record and count the payment data generated by the respective application itself, such as bills. However, the bills counted by each payment application are It cannot completely cover all payment behaviors of users. In other words, the existing payment applications cannot obtain payment data from other payment applications, and it is difficult to comprehensively collect and collect all payment behaviors of users, so users cannot fully, accurately and intuitively understand their own income and expenditure status. Based on this, users cannot obtain comprehensive and accurate income and expenditure statistical analysis or financial advice based on any payment application.

Contents of the invention

The embodiment of the present application provides an electronic payment method, electronic equipment, storage medium, and computer program product. By setting up a payment management application to manage multiple payment applications installed on the electronic equipment, each functional module of each payment application is installed on the electronic equipment. The installed distributed operating system exists in the form of an independent atomic capability module, including the payment capability module. The payment management application completes the payment operation by calling the payment capability module of the authorized and managed payment application, which facilitates the unified management of the user's payment behavior; The management application can also obtain the historical payment data of each payment application through the payment ability module, so as to summarize the payment records and comprehensively count the user's payment behavior, so as to improve the ability to comprehensively analyze the user's payment behavior, and then provide the user with a comprehensive financial analysis report or Financial advice, etc., will help improve user experience.

In the first aspect, the embodiment of the present application provides an electronic payment method, which is applied to an electronic device, and multiple payment applications and payment management applications are installed on the electronic device. The method includes: the payment management application detects that the user is in the payment management application The first payment operation, wherein the first payment operation indicates that the first payment application among multiple payment applications is used to complete the payment function; the payment management application calls the payment function of the first payment application to complete the payment function corresponding to the first payment operation.

That is, the payment management application installed on the electronic device has the function of managing multiple payment applications installed on the electronic device, mainly to manage the payment function of each payment application. When the user opens the payment management application to perform payment operations, the payment management application can call the The payment function of the managed payment application completes the payment, and the payment management application can be the payment management platform installed on the mobile phone described in the following embodiments. For example, the payment management platform can call the payment function of the managed ^AlipayTM application to complete the payment, The amount paid in the payment process is deducted from the ^AlipayTM account or the bank account bound to ^AlipayTM . That is to say, the payment management platform can call the payment capability module of Alipay ^TM to complete the payment function of Alipay ^TM independently.

In a possible implementation of the above first aspect, the payment management application calling the payment function of the first payment application includes: the payment management application calls the payment function of the first payment application to generate a payment code, and displays the payment code on the display interface of the payment management application or the payment management application calls the payment function of the first payment application to display a code scanning window on the display interface of the payment management application.

That is, the user opens the payment management application on the electronic device, such as the payment management platform installed on the mobile phone described in the following embodiments, and the user can click the payment code/scan code payment button in the interface of the payment management platform to choose to open the payment code to send the payment to the merchant. Display for payment, or click the payment code/scan code payment button on the interface of the payment management platform to select to open the scan code window, and scan the payment code displayed by the merchant to make payment.

In a possible implementation of the above first aspect, the payment management application displays prompt information that the payment corresponding to the first payment operation has been completed.

That is, after the payment is completed, a payment success message or a notification window may be displayed on the interface of the payment management application to inform the user that the payment operation has been completed.

In a possible implementation of the first aspect above, the payment management application calls the payment function of the first payment application, and after completing the payment function corresponding to the first payment operation, the method further includes: the payment management application records the completion of the first payment operation Generated first payment data.

That is, for the payment operation performed by the user through the payment management application, the payment management application will generate corresponding payment data for recording. For example, the payment management platform described in the following embodiments records the records of the payment completed by the user through the payment management platform, including recording the payment time, payment amount, etc. The data content contained in the payment data will be described in detail below, and will not be repeated here. repeat.

In a possible implementation of the above first aspect, before the payment management application detects that the user performs the first payment operation in the payment management application, the method further includes: on the display interface of the payment management application or the display interface of the first application The authorization prompt information is displayed to the user in , wherein the authorization prompt information is used to prompt the user whether to authorize the management authority of the payment function of the first payment application to the payment management application; The management authority of the application's payment function is authorized to the payment management application, and a prompt message indicating that the authorization is successful is displayed.

That is, the process for the payment management application to obtain the permission to manage the payment application needs to be authorized by the user. When the user opens the payment management application, the electronic device displays the interface of the payment management application and displays an authorization prompt message on the interface, prompting the user to choose to add Go to the payment application managed in the payment management application to complete the authorization; or when the user operates and opens a certain payment application, the electronic device displays the interface of the payment application and displays an authorization prompt message at the same time, prompting the user to authorize the payment function of the payment application to the payment application. In the payment management application, after the user completes the authorization operation according to the prompt information, the electronic device displays a prompt message indicating that the authorization is successful. For example, when the mobile phone described in the following embodiments with reference to FIG. 11 runs the payment management platform for the first time, a list of payment applications that can be added to the payment management platform for management can be displayed, including ^AlipayTM , ^WeChatTM , and Cloud ^QuickPassTM . The user checks the payment application in the list and clicks the confirm button to complete the authorization operation. After the authorization is successful, the interface of the payment management platform displays a prompt message of authorization success. For another example, when the mobile phone described in the following embodiments with reference to FIG. 8 runs the ^AlipayTM application for the first time, it may display a notification that the running ^AlipayTM application is added to the payment management platform for management, and the user clicks the Add button on the notification. The authorization operation can be completed. After the authorization is successful, the interface of the Alipay ^TM application will display a prompt message of authorization success. It can be understood that the authorization prompt information displayed by the mobile phone running the payment management platform or the Alipay ^TM application may include a check box that allows the user to choose not to display the prompt information during the next operation. Check box 804, so as to prevent the frequent display of the prompt information from causing strong disturbance to the user and affecting the user experience.

In a possible implementation of the above first aspect, the management authority includes that the payment management application can complete the payment by calling the payment function of the first payment application, and the payment management application can obtain the first historical payment data from the first payment application.

That is, after the payment management authority has obtained the payment function management authority of the payment application, not only can the payment function of the payment application be called to perform payment operations, but also the historical payment data recorded on the payment application (ie, the first historical payment data mentioned above) can be obtained. For example, the payment management platform described in the following embodiments can not only call Alipay ^TM for payment, but also obtain historical payment data on Alipay ^TM , including those generated by payment operations completed through Alipay ^TM before being authorized to the payment management platform for management. The payment record data also includes the payment record data generated by the payment operation completed by the user operating the mobile phone to run the Alipay ^TM application after authorization to the payment management platform for management.

In a possible implementation of the above first aspect, the method further includes: the payment management application generates a payment record of at least one user of the electronic device based on the first historical payment data and the second historical payment data, wherein the second historical payment data The data is record data of the payment operation completed by the payment management application calling the first payment application.

That is, after the payment management application obtains the payment function management authority of the payment application, it invokes the payment function of the payment application to perform the payment operation. Recorded historical payment data (i.e. the above-mentioned first historical payment data), the payment management application can summarize the above two types of historical payment data to generate payment records, that is, the accounting classification data collected by the accounting classification module described in the embodiments below . It can be understood that the payment management application can obtain the management authority of the payment function of one or more payment applications, and the accounts logged in on each payment application may be the accounts of the same user or accounts of different users; in another embodiment, the payment The management application or the same payment application may also log in two or more user accounts in different periods. After the payment management application summarizes the above two types of historical payment data, it can conduct sub-account statistics on the historical payment data of different users. Payment record data corresponding to each user is generated.

For example, the payment management platform described in the following embodiments can obtain the historical payment data of one or more users logged in during the running of ^AlipayTM , ^WeChatTM , and Cloud ^QuickPassTM under management, and combine the user's payment through the payment management platform. Corresponding to the historical payment data, the payment management platform can generate payment records corresponding to the accounts of one or more users.

In a possible implementation of the above-mentioned first aspect, the first historical payment data or the second historical payment data include: payment operation time, transaction nature, merchant name, collection account, merchant order number, payment method, payment One or more of account number and serial number.

In a possible implementation of the first aspect above, the method further includes: generating a financial analysis report or financial advice for the corresponding user based on the user's payment records.

That is, the payment management application can generate a financial analysis report or financial advice suitable for the user according to the statistically obtained payment records corresponding to each user. It can be understood that the generation rules of the financial analysis report or the generation rules of the financial advice can be preset in the payment management application, for example, the generation rules can be realized by a professional big data financial management algorithm. For example, the financial management advice big data module of the payment management platform described in the following embodiments has a big data financial analysis function.

In a possible implementation of the first aspect above, the display interface of the payment management application includes an authorization management control.

In a possible implementation of the first aspect above, the method further includes: after the payment management application detects that the user operates the authorization management control, presenting the authorized payment application and the unauthorized payment application to the user; When the application detects that the user confirms the authorization of at least one unauthorized payment application, it obtains the management authority of the payment function of the payment application authorized by the user, and displays a prompt message indicating that the authorization is successful. After the payment management application detects the user's operation on the authorization management control, it deletes the payment application that the user chooses to terminate the authorization.

That is, the interface of the payment management application can be set with an authorization management control capable of managing the authorization or deauthorization of each payment application, such as the application setting button on the payment management platform described in the embodiments below, and the user can click on the payment management platform interface. Click the application setting button to authorize the payment application that has not been authorized, or cancel the authorization of the payment application that has been authorized to be managed by the payment management platform, and stop the management of the payment function of the payment application.

In a possible implementation of the first aspect above, the operating system of the electronic device includes a Hongmeng operating system.

That is, the electronic device running the payment management application can use the HarmonyOS operating system, such as described in the following embodiments. In the HarmonyOS carried by the electronic device, the payment function of each payment application can be an independent payment capability module ( For example, payment FA), after the payment management application obtains the payment function management authority of each payment application, the payment management application can call the payment capability module (payment FA) of each payment application through its own application entry module to complete the payment. Let me repeat.

In the second aspect, the embodiment of the present application provides an electronic device, the device includes: one or more processors; one or more memories; one or more memories store one or more programs, when one or more When the program is executed by one or more processors, the electronic device executes the above-mentioned electronic payment method.

In a third aspect, the embodiment of the present application provides a computer-readable storage medium, on which instructions are stored, and when the instructions are executed on a computer, the computer executes the above-mentioned electronic payment method.

In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program/instruction, and when the computer program/instruction is executed by a processor, the above-mentioned electronic payment method is realized.

For example, the computer program product is a payment management application described in the following embodiments, such as a payment management platform or a wallet application, which is not limited here.

Description of drawings

FIG. 1 shows an application scenario of an electronic payment method provided by an embodiment of the present application.

FIG. 2 is a block diagram of an exemplary system architecture of a Hongmeng operating system 200 provided by an embodiment of the present application.

3A to 3B are schematic diagrams of an operation interface of a payment management application provided by an embodiment of the present application.

FIG. 4 is a schematic composition diagram of a Hongmeng operating system APP provided by an embodiment of the present application.

FIG. 5 is a schematic structural diagram of a payment system provided by an embodiment of the present application.

FIG. 6A is a schematic block diagram of an exemplary structure of a payment management platform 300 provided by an embodiment of the present application.

FIG. 6B is a schematic diagram of a functional interface of a payment management platform 300 provided by an embodiment of the present application.

FIG. 7 is a schematic diagram of the implementation flow of a method for identifying payment applications and adding them to the payment management platform 300 for unified management provided by the embodiment of the present application.

FIG. 8 is a schematic diagram of an interface displayed by the mobile phone 100 provided in the embodiment of the present application.

FIG. 9 is a schematic diagram of an interface displayed by the mobile phone 100 provided in the embodiment of the present application.

FIG. 10 is a schematic diagram of the implementation flow of a method for identifying payment applications and adding them to the payment management platform 300 for unified management provided by the embodiment of the present application.

11A to 11C are schematic diagrams of an interface displayed by the mobile phone 100 provided by the embodiment of the present application.

FIG. 12 is a schematic diagram of an operation flow of payment through the payment management platform 300 provided by the embodiment of the present application.

FIG. 13 is a schematic block diagram showing the structure of a mobile phone 100 provided by the embodiment of the present application.

FIG. 14 is a schematic block diagram showing the structure of another mobile phone 100 provided by the embodiment of the present application.

detailed description

Various aspects of the illustrative embodiments are described below using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that some alternative embodiments may be practiced using some of the described features. For purposes of explanation, specific numbers and configurations are set forth in order to provide a more thorough understanding of the illustrative embodiments. It will be apparent, however, to one skilled in the art that alternative embodiments may be practiced without the specific details. In other instances, well-known features have been omitted or simplified herein in order to avoid obscuring the illustrative embodiments of the application.

In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the embodiments of the present application will be further described in detail below in combination with the accompanying drawings and the embodiments.

Illustrative embodiments of the present application include, but are not limited to, electronic payment methods, electronic devices, storage media, computer program products, and the like.

Fig. 1 shows an application scenario of the electronic payment method applicable to the embodiment of the present application.

This scenario includes a mobile phone 100, on which multiple payment applications are installed, such as Alipay ^™ 101, WeChat ^™ 102, Cloud QuickPass ^™ 103, and bank client 104, etc., and a payment management application 105 is also installed on the mobile phone 100.

When the user needs to pay for goods or services purchased online or offline, the user can open the payment application installed on the mobile phone 100 and scan the payment code provided by the merchant terminal to make payment, or open the payment application installed on the mobile phone 100 to show payment code to pay. For example, the user can operate the mobile phone 100 to run WeChat ^TM 102 or Alipay ^TM 101, scan the merchant's collection code or present the payment code to complete the payment. Secondly, when the user wants to send red envelopes to relatives and friends, for example, he can click the send red envelope button through WeChat ^TM 102 , input the amount of red envelopes and the number of red envelopes to send red envelopes. In addition, when the user needs to transfer money to others, he can also open the bank client 104 on the mobile phone 100, click the transfer button, and input the transfer amount to transfer money. The bank client is, for example, China Construction Bank client, China Merchants Bank client, etc. , without limitation here. As described in the background technology above, payment applications such as Alipay ^TM 101, WeChat ^TM 102, Cloud QuickPass ^TM 103, and bank client 104 only record the payment data generated by the payment operations on their respective applications, and cannot fully record the user's payment behavior .

As mentioned above, in various current payment scenarios, existing payment applications cannot provide payment management services that fully record user payment behaviors, so it is also difficult to conduct statistical analysis of user payment behaviors and give users scientific and reasonable financial advice.

In view of the above problems, the present application provides an electronic payment method. The electronic device used in the electronic payment method of the present application is installed with a plurality of payment applications and a payment management application capable of managing payment applications, wherein each functional module of the payment application is in The distributed operating system carried by the electronic device exists in the form of an independent atomic capability module. The module that enables the payment application to have the payment function is the payment capability module. The payment capability module can not only be called by the corresponding payment application itself, but also Called by the payment management application. Based on the above-mentioned payment capability module that can be called independently, on the one hand, the payment data recorded by the user through the payment application can be sent to the payment management application for collection and payment data collection management; on the other hand, the user can directly use the payment management application Call the corresponding payment capability module of the payment application to complete the payment.

For example, as shown in FIG. 1 , the operating system carried by the mobile phone 100 is a distributed operating system, ^{such as HarmonyOS} . Payment applications such as the bank client 104 have corresponding payment capability modules that can be called independently, and the payment management application 105 installed on the mobile phone 100 can obtain the management authority for the payment function of each payment application after authorization from the user. ^{AlipayTM 101} , ^WeChatTM 102, Cloud ^QuickPassTM 103 and bank client 104 can send payment data generated by payment operations to the payment management application 105; , WeChat ^TM 102 , Cloud QuickPass ^TM 103 or the payment capability module corresponding to the bank client 104 directly performs the payment operation.

It can be understood that the payment management method provided by this application can manage multiple payment applications installed on the mobile phone 100 in a unified manner, and the user can also perform unified payment or collection operations through the payment management application 105, which is convenient for management and convenient To ensure security, the file encryption capability of the operating system carried by the mobile phone 100 and other electronic devices can ensure the security of the payment management application to manage the payment process.

It can be understood that, in other embodiments, the mobile phone 100 in the scene shown in FIG. 1 may also be other electronic devices capable of installing payment applications, including but not limited to mobile phones, smart screens, desktop computers, tablet computers, and laptop computers. , wearable devices, head-mounted displays, mobile email devices, portable game consoles, portable music players, reader devices, personal digital assistants, virtual reality or augmented reality devices, in which one or more processing Electronic equipment such as televisions and other electronic equipment, there is no limitation here.

As an example, the following uses the application of the electronic payment method of the present application to the mobile phone 100 as an example to introduce the specific process of implementing the solution of the present application.

As mentioned above, the distributed operating system carried by the mobile phone 100 may be, for example, the aforementioned HarmonyOS. For ease of understanding, the following uses HarmonyOS as an example to describe the distributed operating system and how to realize the process of managing payment applications based on HarmonyOS.

FIG. 2 shows a block diagram of an exemplary system architecture of HarmonyOS 200 .

As shown in FIG. 2 , HarmonyOS 200 adopts a layered architecture as an example. The layered architecture divides HarmonyOS 200 into several layers, and each layer has a clear role and division of labor. Layers communicate through software interfaces. In some embodiments, HarmonyOS 200 is divided into four layers, which are application layer 210 , application framework layer 220 , system service layer 230 and kernel layer 240 from top to bottom. In some other embodiments, HarmonyOS 200 may also be divided into other number of hierarchical structures, which is not limited here.

The application layer 210 may include a series of application programs (Application, APP) such as a system application 211 and an extension application 212 (or a third-party application). In some embodiments of the present application, the extension application 212 includes, but is not limited to, payment applications such as the aforementioned ^AlipayTM 101, ^WeChatTM 102, UnionPay Cloud ^QuickPassTM 103, bank client 104, and payment management application 105, etc. Do limit.

The application framework layer 220 provides multilingual frameworks such as Java/C/C++/JS for the application layer 210, including an interface (UserInterface, UI) framework 221, a user program framework 222 and a capability framework 223, and a multilingual framework application programming interface (application programming interface, API) and framework APIs for multiple programming languages. Wherein, the application framework layer 220 includes some predefined functions. Wherein, the UI framework 221 includes a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc., which will not be repeated here. The user program framework 222 and capability framework 223 are multilingual frameworks provided by the application framework layer for applications, including providing various feature capabilities required by applications for applications, such as payment capabilities provided for payment applications.

It can be understood that an application in HarmonyOS 200 consists of one or more feature capabilities (Feature Ability, FA) or particle capabilities (Particle Ability, PA). Among them, FA has a user interface (User Interface, UI), which provides the ability to interact with users, also known as atomic capabilities or meta-capacities. The ability to run tasks in the background and a unified data access abstraction. Applications developed based on FA/PA can realize specific business functions, support cross-device scheduling and distribution, and provide users with a consistent and efficient application experience. In some embodiments of the present application, the payment application on the mobile phone 100 is an application program developed based on the payment feature capability (that is, the above-mentioned payment capability module, hereinafter referred to as payment FA).

The user can click the application icon of each application program in the desktop program of the mobile phone 100 to start the operation of the application program. It can be understood that the application icon of each application program is provided by the application entry module. The application entry module will be described in detail below and will not be repeated here. repeat. In the embodiment of the present application, as shown in FIG. 1, the user can click the application icon of the payment management application 105 in the desktop application program of the mobile phone 100 to start the payment management application 105. When the user performs a payment operation through the payment management application 105, If the first payment application set in the payment management application 105 is Alipay ^TM 101, then the application entry module of the payment management application 105 directly calls the payment class FA of Alipay ^TM 101 to complete the payment when paying, wherein the payment class FA of Alipay ^TM 101 It can independently operate and provide the payment function of Alipay ^TM 101, and then deduct corresponding money from the user's Alipay account.

As an example, the main interface of the payment management application 105 can refer to the interface of the payment management platform 300 shown in FIG. 3A. For example, referring to operation ① shown in FIG. In the display interface, the user clicks on the payment code option 302 to present the payment code for payment. In the interface shown in FIG. 3B , the user can also click on the scan option 303 to open the scan code window and scan the code for payment.

The system service layer 230 is the core of HarmonyOS 200 , and the system service layer 230 provides services to the applications in the application layer 210 through the application framework layer 220 . The system service layer 230 includes:

System Basic Capability Subsystem Set 231: Provides basic capabilities for running, scheduling, and migrating distributed applications on multiple devices, including distributed soft bus, distributed data management, distributed task scheduling, and Ark multilingual runtime Subsystem, common base library subsystem, multi-mode input subsystem, graphics subsystem, security subsystem, AI subsystem, etc. Among them, the Ark multilingual runtime subsystem provides the C/C++/JS multilingual runtime and the basic system class library, and also provides static Java programs using the Ark compiler (that is, the Java language development in the application program or framework layer) part) provides the runtime.

Basic software service subsystem set 232: provides common and general software services for HarmonyOS 200, and is composed of event notification subsystem, telephone subsystem, multimedia subsystem, DFX subsystem, MSDP&DV subsystem and other subsystems.

Enhanced software service subsystem set 233: Provide HarmonyOS 200 with differentiated capability-enhanced software services for different devices, including smart screen dedicated business subsystems, wearable dedicated business subsystems, IoT dedicated business subsystems, etc. system composition.

Hardware service subsystem set 234: provides hardware services for distributed operating systems, and is composed of location service subsystems, biometric identification subsystems, wearable dedicated hardware service subsystems, IoT dedicated hardware service subsystems and other subsystems.

According to the deployment environment of different equipment forms, the interior of the basic software service subsystem set, enhanced software service subsystem set, and hardware service subsystem set can be tailored according to the granularity of the subsystem, and the interior of each subsystem can be tailored according to the granularity of the function.

The kernel layer 240 is a layer between hardware and software. The kernel layer of HarmonyOS 200 includes: a kernel subsystem 241 and a driver subsystem 242 .

Wherein, the kernel subsystem 241 can adopt a multi-kernel design because the HarmonyOS 200 can adopt a multi-kernel design, so the kernel subsystem 241 supports selection of a suitable OS kernel for different resource-constrained devices. The Kernel Abstract Layer (KAL) on the kernel subsystem 241 provides basic kernel capabilities to the upper layer by shielding multi-kernel differences, including process/thread management, memory management, file system, network management, and peripheral management.

The driver subsystem 242 is the driver framework (HDF) of HarmonyOS 200, and is also the basis for the open hardware ecology of the distributed system, providing a unified peripheral access capability and a driver development and management framework. The kernel layer 240 includes at least a display driver, a camera driver, an audio driver, and a sensor driver.

It can be understood that the above-mentioned system architecture shown in FIG. 2 does not constitute a limitation of the system architecture of HarmonyOS 200. In other embodiments, HarmonyOS 200 may have more or fewer system architecture structures than those shown in FIG. It can be other forms of system architecture, which is not limited here.

It can be understood that the application release form on HarmonyOS 200 is APP Pack (Application Package, APP for short), that is, the above-mentioned HarmonyOS APP. For ease of understanding, FIG. 4 shows a schematic composition diagram of a HarmonyOS APP.

As shown in Figure 4, a HarmonyOS APP is composed of one or more HAP (HarmonyOS Ability Package) packages and a pack.info file describing the properties of the APP Pack. Among them, HAP is the deployment package of the meta-capability (Ability), and the HarmonyOS application code is developed around the Ability component, which is composed of one or more Abilities. Ability is divided into two types: FA and PA. As mentioned above, FA/PA is a basic component unit of an application, which can realize specific service functions, and will not be repeated here.

It can be understood that a HAP is a module package composed of code, resources, third-party libraries and application manifest files, including two types of Entry and Feature. Among them, Entry is the entry module of the application, and an APP can only have one Entry module. Entry Modules can be installed independently, and provide desktop application icons for users to click to start corresponding applications. For example, Alipay ^TM 101 has a unique Entry module, and payment management application 105 also has a unique Entry module; Feature is the dynamic characteristic of the application Module, an APP can contain one or more Feature modules. As shown in FIG. 4, Entry.hap may include the above-mentioned Ability component, database (libs), resource file (resources), and a configuration file (config.json) describing configuration information such as resolution and security parameters.

It can be understood that the application name, function options, and interface display of the payment management application 105 are not limited to the payment management platform 300 shown in FIG. Various functional modules of the payment management application 105 may be displayed in other forms of interfaces, which are not limited here.

For ease of description, the following will take the payment management application 105 as the payment management platform 300 shown in FIG. 3A as an example, wherein the structure of the payment management platform 300 and the introduction of specific function options will be described in detail below, and will not be repeated here. .

It can be understood that the aforementioned payment applications such as ^AlipayTM 101, ^WeChatTM 102, Cloud ^QuickPassTM 103 and bank client 104 and the payment management platform 300 provided by this application form a payment system in HarmonyOS 200. As an example, FIG. 5 shows A schematic diagram of the architecture of a payment management system is presented.

As shown in FIG. 5 , the payment system includes Alipay ^™ 101 , WeChat ^™ 102 , Cloud QuickPass ^™ 103 and a payment management platform 300 . Among them, Alipay ^TM 101 has an application entry module 311 and a payment FA 312 , WeChat ^TM 102 has an application entry module 321 and a payment FA 322 , and UnionPay ^TM 103 has an application entry module 331 and a payment FA 332 . Among them, when ^AlipayTM 101, ^WeChatTM 102, and UnionPayTM 103 are installed on the mobile phone 100 equipped with HarmonyOS 200, the payment category ^FA312 of ^AlipayTM 101, the payment category ^FA322 of ^WeChatTM 102, and UnionPayTM 103 are completed. The payment class FA332 is authorized to register on the FA management module 201 in the HarmonyOS 200. It can be understood that the FA management module 201 is used to manage various FAs of any application installed on the HarmonyOS 200, which is not limited here.

It can be understood that the payment application installed on the mobile phone 100 equipped with HarmonyOS 200 includes not only the application entry module, but also the payment FA. Registration authorization, the payment management platform 300 obtains the management authority of the payment FA of each payment application based on the user's authorization behavior, that is, the management authority of the payment function of each payment application is obtained, and the payment management platform 300 can then use the unified application The entry module directly invokes the payment FA of each payment application to perform payment operations, and the payment management platform 300 can also obtain all payment data on the corresponding payment application based on each payment FA, including historical payment data, for summary management. For example, HarmonyOS 200 scans the above-mentioned payment category FA322 of ^WeChatTM 102 and payment category ^FA332 of UnionPayTM 103 and requests the user to authorize the management of the above-mentioned payment categories FA322 and 332. FA322 and 332 are authorized to the payment management platform 300 for management. After the user agrees to authorize, the payment management platform 300 can directly call the above-mentioned payment type FA322 or 332 through the unified Entry.hap when performing payment operations, and can also obtain WeChat based on the above-mentioned payment type FA322 The receipt and payment data on ^TM 102 and the payment data on Cloud QuickPass ^TM 103 are obtained based on the payment type FA332.

Specifically, the payment management platform 300 provides a unified application entry module (i.e. Entry.hap). When performing payment operations, the unified Entry.hap can call the payment class FA of the payment application added to the payment management platform 300 for unified management. , provide a unified payment entry or payment channel to complete the payment operation, including generating a unified payment code and providing a unified scanning code entry, etc. For example, the payment management platform 300 shown in Figure 5 is added to the platform through the Entry.hap pair of the platform The managed Alipay ^TM 101 manages the payment, and when paying, the payment management platform 300 directly calls the payment class FA312 of Alipay ^TM 101 through Entry.hap to generate a payment code for payment.

It can be understood that if there are many payment applications added to the payment management platform 300 to manage payment, the user can set the payment order of each payment application, and each payment application can still set the payment order for payment channels such as bank cards and credit cards managed by the payment application , when the payment management platform 300 calls the payment FA of the payment application to perform the payment operation, the payment is made through the first priority payment channel set in the payment application by default. For example, in the above example, when the payment management platform 300 calls the payment class FA312 of Alipay ^TM 101 for payment, if the first order payment channel set in Alipay ^TM 101 is a bank credit card, then the payment process of the payment management platform 300 is Complete the payment by debiting the bank's credit card bound on Alipay ^TM 101. In addition, it is understandable that even though the payment management platform 300 can invoke various payment types of FAs to perform payment operations after authorization from the user, if the user is still paying by opening the payment application, such as ^AlipayTM 101, to perform payment operations, ^AlipayTM The entry module 311 of 101 invokes the payment type FA312 of ^AlipayTM 101 to perform payment operations, and the payment management platform 300 can obtain payment data related to the payment operation based on the management authority of the payment type FA312.

It can be understood that if the FA management module 201 of HarmonyOS 200 scans the payment FA and then notifies the user to authorize it to be added to the payment management platform 300 for unified management, but the user authorization is not obtained, the payment management platform 300 cannot correspond to the payment FA. Unified payment management by the payment application of the payment application, and the receipt and payment data on the payment application cannot be obtained. At this time, if the user operates the mobile phone 100 to run the payment application to perform the payment operation, the application entry module of the payment application will automatically call the payment class FA of the payment application to complete the payment operation. For example, when the user operates the mobile phone 100 to run Alipay ^TM 101 to perform a payment operation, the application entry module 311 of Alipay ^TM 101 calls the payment class FA312 to complete the payment operation.

It can be understood that the collection and payment data collected by the payment management platform 300 when providing a unified payment channel based on Entry.hap and the collection and payment data obtained by the payment management platform 300 through the payment FA of each payment application can be aggregated and counted. Complete consumption information statistics, and then provide users with classified accounting functions and consumption financial advice based on the statistical receipt and payment data.

It can be understood that the payment management platform 300 provided in this application can also have the function of managing fund accounts such as savings cards and credit cards that most payment applications currently have, and details will not be repeated here.

It can be understood that the above-mentioned payment management platform 300 may be a HarmonyOS APP, or a payment application on the HarmonyOS 200, such as a Huawei ^TM wallet application. In some other embodiments, the above-mentioned payment management platform 300 may also be other services or applications with payment and/or payment management functions, which is not limited here. It can be understood that the payment management platform 300 installed on the mobile phone 100 can also authorize other electronic devices interconnected with the mobile phone 100 to provide payment codes for payment operations, that is, the payment management platform 300 can support multi-device coordination for payment, and the payment management platform 300 supports multi-device The coordinated function will be described in detail below and will not be repeated here.

As an example, FIG. 6A shows a schematic structural block diagram of a payment management platform 300 .

As shown in FIG. 6A , the payment management platform 300 includes a payment FA management module 310 , an accounting classification module 320 , a multi-device collaborative communication module 330 and a wealth management advice big data module 340 . Among them, the functions of each module include but are not limited to the following descriptions:

The payment FA management module 310 can manage the payment FA added to the payment management platform 300 authorized by the user, including managing operations such as adding and canceling the authorization of the payment FA, and can also be used for the unified application of the payment management platform 300 The entry calls the payment FA managed by the payment FA management module 310 to complete the payment operation through the corresponding payment application, for example, calling the payment FA added to the payment application uniformly managed by the payment management platform 300 through a unified Entry.hap, Payment is made by uniformly generating payment codes. This function can refer to the relevant description in Figure 5 above, and will not be repeated here. It can be understood that before the payment FA management module 310 calls the payment FA of each payment application through the unified Entry.hap, it can manage the payment order of each payment application. For example, the payment FA management module 310 can respond to The user's setting operation adjusts the payment order of each payment application, and calls the payment FA of each payment application to perform payment operations according to the payment order. In some other embodiments, the payment FA management module 310 may also set a default payment order for each payment application added to the payment management platform 300 to manage payment, which is not limited here.

It can be understood that the payment FA management module 310 can send the receipt and payment data on each payment application acquired through the payment FA to the accounting classification module 320 , financial advice big data module 340 and basic function library 350 .

The accounting classification module 320 can classify and make statistics on the receipt and payment data generated during the payment operation through the payment management platform 300 and the receipt and payment data on each payment application obtained by the payment FA management module 310 from each payment FA, and obtain Bookkeeping classification data, for example, classify the above receipt and payment data according to the type of receipt and payment. The types of receipt and payment may include, for example, consumption types such as food, clothing, and daily necessities, and may also include fund transfer types such as transfers, red envelopes, and income. This is not limited. In other embodiments, the accounting classification module 320 can perform operations such as addition and subtraction on the receipt and payment data within a certain period of time to calculate the total expenditure and total income, such as statistics of monthly total expenditure and monthly total income, etc., the accounting classification module 320 The receipt and payment data within a certain period of time can also be used to calculate the proportion of various expenditures according to the above classification types, for example, the proportion of monthly daily necessities consumption expenditure to total monthly expenditure, etc. can be calculated. It can be understood that the classification and statistical results of the receipt and payment data by the accounting classification module 320 can be provided to the financial management suggestion data module 340 to determine financial management suggestions that match the user's income and expenditure.

It can be understood that the payment management platform 300 can obtain the management authority of the payment function of one or more payment applications, for example, obtain the payment function management authority of payment applications such as ^AlipayTM , ^WeChatTM , and Cloud ^QuickPassTM , and the possibility of logging in to each payment application It is the account of the same user, or it may be the account of different users; in another embodiment, two or more user accounts may be logged in at different periods on the payment management platform 300 or the same payment application, and the payment management platform After summarizing the above two types of historical receipt and payment data, the billing and classification module 320 of 300 can perform account-by-account statistics on the historical receipt and payment data of different users, and generate billing and classification data corresponding to each user.

The multi-device cooperative communication module 330 is used to manage the communication and interconnection between other electronic devices and the mobile phone 100, so as to authorize other electronic devices to provide payment and payment functions and accounting functions of the payment management platform 300, such as smart watches or smart hands worn by users. The ring can be interconnected with the mobile phone 100 through the multi-device collaborative communication module 330 and obtain user authorization. When paying, the user can display the payment code through the smart watch or smart bracelet to perform the payment operation. In other embodiments, the user can also use the smart watch. Or a smart bracelet to check receipt and payment bills or financial advice, etc., there is no limit here. In some embodiments, the function of the multi-device cooperative communication module 330 may be implemented by the distributed soft bus in the aforementioned HarmonyOS 200, which is not limited here.

The wealth management advice big data module 340 is used to perform big data analysis on the receipt and payment data generated during the payment operation through the payment management platform 300 and the receipt and payment data on each payment application acquired by the payment FA management module 310 from each payment FA , and generate financial advice based on the preset financial management algorithm for user reference. In some other embodiments, the financial management suggestion big data module 340 can also perform financial management analysis based on the classification and statistical results obtained by processing the above-mentioned receipt and payment data by the accounting classification module 320, and generate financial management suggestions for user reference, without limitation here .

The basic function program library 350 is used to provide an interactive application program interface (Application Program Interface, API) between the payment management platform 300 and HarmonyOS 200, to support the above-mentioned function modules of the payment management platform 300 to call the system function to complete the communication between the user and the user. interaction. For example, based on the function buttons presented by the payment management platform 300 and provided to the user by the above functional modules, displaying the chart of the function buttons needs to call the image drawing function on the system.

It can be understood that for the application installed in HarmonyOS 200, the system will uniformly scan the FA in the application. If it is a payment application with payment FA, the system can remind the user to add the payment application to the payment management platform 300 for unification. manage.

Based on the structure of the payment management platform 300 shown in FIG. 6A , FIG. 6B shows a schematic diagram of a functional interface of the payment management platform 300 .

As shown in Figure 6B, the functional interface of the payment management platform 300 includes a payment code/scanning code payment button 601 (that is, the payment code/scanning code payment button 301 shown in Figure 3A above), an accounting edit button 602, and a wealth management management button 603 , an application setting button 604 and a device management button 605 .

Based on the functional support provided by the functional modules shown in FIG. 6A , the user can trigger an input event of the corresponding function by clicking each functional button shown in FIG. 6B .

The user clicks the payment code/scan code payment button 601 to present the payment code or open the scan code window to scan the payment code to perform the payment operation.

The user clicks the bookkeeping edit button 602 to view the payment details. The interface displaying the payment details can be sorted by the payment time, or can be displayed according to the payment type corresponding to the payment. The user can also display the payment details on the interface Set the display format on the above, and there is no limit here.

The user clicks the financial management button 603 to view financial analysis reports and financial advice, etc. For example, the interface opened by the financial management button 603 can display a financial analysis report, and a brief summary of financial advice is displayed below the report. There is no limitation here.

The user clicks the application setting button 604 to manage the payment application added to the unified management on the platform 300. The user can set the payment order of the payment application uniformly managed by the platform 300 on the interface opened by the application setting button 604, and can also choose to add a payment application. Trigger acquisition of payment FA that has not yet been added to the unified management on the platform 300, and authorize the addition.

The user clicks the device management button 605 to manage other electronic devices that have obtained the unified application entry call authority for unified management and payment on the payment management platform 300, such as smart watches or smart bracelets. The user can click the device management button 605 to open Add device authorization on the interface, or deauthorize a device that has been added, delete the device and other operations.

In some other embodiments, the user's consumption data can also be displayed through statistical charts on the functional interface of the platform 300 shown in FIG. Financial advice based on the analysis of the receipt and payment data of the past month or half a year can be displayed for user reference, and there is no limitation here.

Based on the structure of the payment management platform 300 shown in FIG. 6A and the interface of the payment management platform 300 shown in FIG. 6B , the specific implementation process of the electronic payment method of this application through the payment management platform 300 will be introduced in detail below in combination with specific embodiments.

Embodiment one

The embodiment of this application continues to take the mobile phone 100 configured with HarmonyOS 200 as an example. Based on the structural characteristics of HarmonyOS 200 introduced above, the process of managing payment applications by the mobile phone 100 through the payment management platform 300 is described in detail in combination with the flow chart. The embodiment of this application mainly introduces a method of adding payment applications to the payment management platform 300 for unified management.

FIG. 7 shows a schematic diagram of an implementation process of a method for identifying payment applications and adding them to the payment management platform 300 for unified management. It can be understood that the execution subject of each step shown in FIG. 7 is the mobile phone 100 .

As shown in Figure 7, the method includes the following steps:

701: Install an application program on the mobile phone 100 .

Specifically, when the user uses the mobile phone 100, he can install some application programs according to his needs. For example, if the user wants to install Alipay ^™ , he can open the application store on the mobile phone 100 to search for Alipay ^™ and click Install. The installation of ^AlipayTM can be completed.

702: The mobile phone 100 determines whether the above-mentioned installed application is a payment application. If yes, execute step 703; otherwise, do not process.

Specifically, the HarmonyOS 200 carried by the mobile phone 100 can identify whether there is a payment-type FA in the installed application program, for example, by scanning the FA characteristic parameters of the installed application program to identify whether there is a payment-type FA in the application program. That is to say, after the application is installed, the operating system of the mobile phone 100 can trigger the acquisition of the FA of the application and identify whether there is a payment-type FA in it. If the installed application has a payment-type FA, the application is a payment application; if the installed application does not have a payment-type FA, the application is another application, not a payment application.

703: The mobile phone 100 adds the above-mentioned installed applications to the list of payment applications to be managed.

Specifically, as shown in FIG. 2 above, the HarmonyOS 200 carried on the mobile phone 100 can manage and call various types of FAs in each application program, and add identifiable payment-type FAs to the list of payment applications in the system. It should be understood that the list includes payment-type FAs of various payment applications installed on the mobile phone 100 .

704: When the mobile phone 100 runs the payment application, prompt the user whether to add the application to the payment management platform 300 for management.

Specifically, when the mobile phone 100 runs the above-mentioned installed payment application, it can notify the user on the interface of the application whether to add the application to the payment management platform 300 for management. When the payment application is run for the first time, a confirmation notification is sent to the user, and the notification may include a check box through which the user can choose not to pop up the confirmation notification when the payment application is run next time.

As an example, you can refer to the interface shown in Figure 8. When the ^AlipayTM installed on the mobile phone 100 runs for the first time, when the user completes the initial application settings and enters the ^AlipayTM interface, the above-mentioned confirmation notification 801 can be displayed on the top of the interface, and the content of the notification can be referred to in Figure 8. As shown in "The system has detected that this application can be added to the payment management platform for unified management, please confirm whether to add it?", the user can click the "Add" button 802 to confirm adding the payment application to the payment management platform 300 for management , the user can also click the “cancel” button 803 to refuse to add the payment application to the payment management platform 300 for management. It can be understood that in the confirmation notification 801 shown in FIG. 8 , a check box 804 may also be displayed below the above-mentioned "Add" button 802 and "Cancel" button 803, and the user checks the check box 804 and closes the confirmation notification 801. , the confirmation notification will not pop up when the mobile phone 100 runs the payment application next time. In some other embodiments, the content and display form of the confirmation notification may also be other, which is not limited here.

705: For the payment applications added to the payment management platform 300, the mobile phone 100 uses the unified application portal of the platform to call the payment FA corresponding to each payment application to perform payment operations.

Specifically, after the above-mentioned payment application is added to the payment management platform 300, the user can display the payment code on the payment management platform 300 when making a payment and select the application to make the payment. As an example, as shown in FIG. 6B , the user can click the payment code/code scanning payment button 601 on the payment management platform 300 to display the payment code. It can be understood that when the user clicks the button 601, the interface of the payment management platform 300 may pop up " "Payment Code" option card and "Scan" option card, as shown in Figure 9, the user can click the "Payment Code" option card 901 to display the payment code, and click the "Scan" option card 902 to open the scan code entry and display the scan code interface. In some other embodiments, a quick code scan button 606 may be added in the search box on the interface shown in FIG. 6B , so as to facilitate the user to perform a shortcut operation to open the code scan entry.

It can be understood that the method of adding the payment application to the unified management of the payment management platform 300 is not limited to the method described in steps 701 to 705 above, another method of adding the payment application to the unified management of the payment management platform 300 is described below through another embodiment .

Embodiment two

Based on the structural features of HarmonyOS 200 introduced above, the process of managing payment applications by mobile phone 100 through payment management platform 300 will be described in detail below in conjunction with the accompanying drawings. The embodiment of this application mainly introduces the unified management of adding payment applications to payment management platform 300 another method of .

FIG. 10 shows a schematic flow chart of a method for identifying payment applications and adding them to the payment management platform 300 for unified management. It can be understood that the execution subject of each step shown in FIG. 10 is the mobile phone 100 .

As shown in Figure 10, the method includes the following steps:

1001: Running the payment management platform 300.

Specifically, the user clicks on the payment management platform 300 installed on the mobile phone 100 , and the mobile phone 100 runs the payment management platform 300 . When the mobile phone 100 runs the payment management platform 300 for the first time, it can display a list of payment applications entered in the system in the form of a pop-up window on its main function interface for the user to choose to add to the payment management platform. Refer to the pop-up window 1101 shown in FIG. 11A . The user selects to check or uncheck the check boxes 1102 behind each payment application displayed on the pop-up window 1101 , and then clicks the confirmation button 1103 to complete the addition. After the addition is completed, the mobile phone 100 may display a prompt message indicating successful authorization, which will not be repeated here.

In another embodiment, the user can also click the application setting button 604 on the main function interface of the payment management platform 300 displayed on the mobile phone 100. Referring to operation ② shown in FIG. 11B, the mobile phone 100 opens the setting interface 1104 in response to the user operation, Referring to FIG. 11C , the user can click the Add button 1105 on the setting interface 1104 to open the payment application list entered in the system and select the application to be added. Referring to the above interface shown in FIG. 11A , click the Confirm button 1103 to complete the addition. After the addition is completed, the mobile phone 100 may display a prompt message indicating successful authorization, which will not be repeated here.

It can be understood that the payment applications that have been entered into the list by the system can be the HarmonyOS 200 carried on the mobile phone 100, which scans the FAs to filter out the payment FAs and add them to the list of payment FAs in the system. The payment applications corresponding to the corresponding payment FAs are It is a payment application that has entered the list in the above system. The user can click the sequence setting button 1106 corresponding to each payment application on the interface shown in FIG. 11C to adjust the setting sequence. It can be understood that the sequence setting button 1106 corresponding to the first payment application can be displayed as "default", etc. In other words, the order setting button 1106 corresponding to the payment application that is not in the first order may display an icon containing an upward arrow, which is not limited here. Correspondingly, referring to the interface shown in FIG. 11C, the user can also click the delete button 1107 corresponding to each payment application under the delete application option on the interface shown in FIG. 11C to delete the corresponding payment application from the payment management platform 300, that is, not Then manage the payment operation in a unified manner.

In some other embodiments, the payment management platform 300 may also be a wallet application installed on the mobile phone 100 or other payment applications having the payment management capability described in the embodiments of this application, which is not limited here.

1002: Display the payment applications that have been entered in the list, for the user to choose to add to the payment management platform 300 .

Specifically, referring to the interface shown in FIG. 11A , the list of payment applications installed on the mobile phone 100 is displayed on the pop-up window 1101. It can be understood that the system of the mobile phone 100 records each payment application by identifying the payment type FA on each payment application. The user's operation of selecting to add to the payment management platform 300 on the pop-up window 1101 has been described in step 1001 above, and will not be repeated here.

1003: Set a payment sequence in response to user operations.

Specifically, on the payment management platform 300 of the mobile phone 100, the default payment order can be determined by preset rules, for example, the payment order is set by default according to the time of adding each payment application. It can be understood that after the payment application is added to the payment management platform 300, refer to As shown in FIG. 11C and related descriptions above, the user can set the payment order under the setting payment order option shown in FIG. 11C . For specific operations, refer to the relevant description in the above step 1101 , which will not be repeated here.

It can be understood that each payment application added to the payment management platform 300 for unified management can call the payment FA corresponding to each payment application through the unified Entry.hap provided by the payment management platform 300 to perform payment operations, for example, in the payment management platform 300 Click the payment code/scan code payment button 601 on the interface to make payment. As mentioned above, the payment applications that are not added to the payment management platform 300 for unified management can be authorized by the user, so that the payment management platform 300 can obtain payment data and income data generated by independent payment operations on each payment application.

The following describes in detail the execution flow of the unified payment operation through the payment management platform 300 in another embodiment.

Embodiment Three

Based on the method introduced in the above-mentioned embodiment 1 or embodiment 2, after completing the relevant settings of the payment management platform 300 to manage the payment application, the embodiment of this application will introduce the specific payment process of the payment management platform 300 provided by this application in conjunction with the specific flow chart. Operating procedures.

FIG. 12 shows a schematic diagram of an operation flow of payment through the payment management platform 300 . It can be understood that the execution subject of each step shown in FIG. 12 is the mobile phone 100 .

As shown in Figure 12, the process includes the following steps:

1201: Open the interface of the payment management platform 300 in response to a user operation.

Specifically, the user can find the application icon of the payment management platform 300 in the desktop application program of the mobile phone 100, click the icon, and the mobile phone 100 runs the payment management platform 300, and this process will not be repeated here. Wherein, the opened interface of the payment management platform 300 can be referred to as shown in FIG. 6B , which will not be repeated here.

1202: In response to the payment method selected by the user according to the payment scenario, determine whether to display the payment code. If yes, go to step 1203; if not, go to step 1204.

Specifically, referring to the various payment scenarios shown in Figure 2 above, for example, in the scenario where the user is purchasing goods or services offline as shown in Figure 2, the user can scan himself or not according to whether the payment method supported by the merchant is the merchant's scan. Select the payment method, if yes, the user needs to show the payment code, that is, go to step 1203;

1203: Display the payment code in response to the user operation.

Specifically, the operation of the user operating the mobile phone 100 to open the payment code on the main function interface of the payment management platform 300 can refer to the relevant description of step 705 in the first embodiment above, that is, click the payment code/code scanning payment button shown in FIG. 6B 601. On the opened interface shown in FIG. 9, click the "Payment Code" option card 901 to display the payment code, which will not be repeated here.

1204: In response to a user operation, enable a code scanning function.

Specifically, for the user to operate the mobile phone 100 and open the code scanning function on the main function interface of the payment management platform 300, please refer to the relevant description of step 705 in the first embodiment above, that is, click the payment code/code scanning payment shown in Figure 6B Button 601, click on the opened interface shown in Figure 9 and click on the "scan" option card 902 to open the code scanning entry and display the code scanning interface, which will not be repeated here.

1205: Complete the payment based on the payment order set on the payment management platform 300, and record information such as consumption amount and type.

Specifically, the payment management platform 300 completes the payment based on the set payment sequence. For example, ^referring to the interface shown in FIG. , the user can enter the set payment password or fingerprint authentication payment to complete the payment verification, and the payment management platform 300 will pay the corresponding amount through the default Alipay ^TM . The payment management platform 300 records the data related to the payment order generated during the payment process, such as consumption amount, consumption type, consumption time, consumption location, payment serial number and other information, which is not limited here.

It can be understood that in the Alipay ^TM application, the deduction can be completed based on the deduction sequence set in the application, and there is no limitation here.

As an example, FIG. 13 shows a schematic structural diagram of a mobile phone 100 .

As shown in FIG. 13 , the mobile phone 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charging management module 140, a power management module 141, a battery 142, Antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, earphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, A display screen 194, a subscriber identification module (subscriber identification module, SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, bone conduction sensor 180M, etc.

The processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processing unit (graphics processing unit, GPU), an image signal processor ( image signal processor (ISP), controller, video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or neural network processor (neural-network processing unit, NPU), etc. Wherein, different processing units may be independent devices, or may be integrated in one or more processors.

The controller can generate an operation control signal according to the instruction opcode and timing signal, and complete the control of fetching and executing the instruction. In the embodiment of the present application, the processor 110 may execute the electronic payment method provided in the present application through a controller.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to use the instruction or data again, it can be called directly from the memory. Repeated access is avoided, and the waiting time of the processor 110 is reduced, thus improving the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuitsound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver (universal asynchronous receiver) /transmitter, UART) interface, mobile industry processor interface (mobile industry processor interface, MIPI), general-purpose input and output (general-purpose input/output, GPIO) interface, subscriber identity module (subscriber identity module, SIM) interface, and/or A universal serial bus (universal serial bus, USB) interface, etc.

The USB interface 130 is an interface conforming to the USB standard specification, specifically, it may be a Mini USB interface, a Micro USB interface, a USB Type C interface, and the like. The USB interface 130 can be used to connect a charger to charge the mobile phone 100, and can also be used to transmit data between the mobile phone 100 and peripheral devices. It can also be used to connect headphones and play audio through them. This interface can also be used to connect other electronic devices, such as AR devices.

It can be understood that the interface connection relationship between modules shown in the embodiment of the present invention is only a schematic illustration, and does not constitute a structural limitation of the mobile phone 100 . In other embodiments of the present application, the mobile phone 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

The charging management module 140 is configured to receive a charging input from a charger. Wherein, the charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 can receive charging input from the wired charger through the USB interface 130 . In some wireless charging embodiments, the charging management module 140 can receive wireless charging input through the wireless charging coil of the mobile phone 100 . While the charging management module 140 is charging the battery 142 , it can also provide power for electronic devices through the power management module 141 .

The wireless communication function of the mobile phone 100 can be realized by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in handset 100 can be used to cover single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: Antenna 1 can be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 can provide wireless communication solutions including 2G/3G/4G/5G applied on the mobile phone 100 . The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA) and the like. The mobile communication module 150 can receive electromagnetic waves through the antenna 1, filter and amplify the received electromagnetic waves, and send them to the modem processor for demodulation. The mobile communication module 150 can also amplify the signals modulated by the modem processor, and convert them into electromagnetic waves through the antenna 1 for radiation. In some embodiments, at least part of the functional modules of the mobile communication module 150 may be set in the processor 110 . In some embodiments, at least part of the functional modules of the mobile communication module 150 and at least part of the modules of the processor 110 may be set in the same device.

The wireless communication module 160 can provide applications on the mobile phone 100 including wireless local area networks (wireless local area networks, WLAN) (such as wireless fidelity (wireless fidelity, Wi-Fi) network), bluetooth (bluetooth, BT), global navigation satellite system ( Global navigation satellite system (GNSS), frequency modulation (frequency modulation, FM), near field communication (near field communication, NFC), infrared technology (infrared, IR) and other wireless communication solutions. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2 , frequency-modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110 . The wireless communication module 160 can also receive the signal to be sent from the processor 110 , frequency-modulate it, amplify it, and convert it into electromagnetic waves through the antenna 2 for radiation.

In some embodiments, the antenna 1 of the mobile phone 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the mobile phone 100 can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and/or IR technology, etc. The GNSS may include a global positioning system (global positioning system, GPS), a global navigation satellite system (globalnavigation satellite system, GLONASS), a Beidou satellite navigation system (beidou navigationsatellite system, BDS), a quasi-zenith satellite system (quasi-zenith) satellite system (QZSS) and/or satellite based augmentation systems (SBAS).

The mobile phone 100 realizes the display function through the GPU, the display screen 194, and the application processor. The GPU is a microprocessor for image processing, and is connected to the display screen 194 and the application processor. GPUs are used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information. In the embodiment of the present application, the operation interface of the payment management platform 300 and the QR code displayed by the user when paying are processed by the GPU to render the corresponding graphics data and then displayed on the display screen 194 of the mobile phone 100 .

The display screen 194 is used to display images, videos and the like. The display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (active-matrix organic light emitting diode). AMOLED), flexible light-emitting diode (flex light-emitting diode, FLED), Mini-LED, Micro-LED, Micro-OLED, quantum dot light-emitting diodes (quantum dot light emitting diodes, QLED), etc. In some embodiments, the mobile phone 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

The mobile phone 100 can realize the shooting function through ISP, camera 193 , video codec, GPU, display screen 194 and application processor.

The ISP is used for processing the data fed back by the camera 193 . For example, when taking a picture, open the shutter, the light is transmitted to the photosensitive element of the camera through the lens, and the light signal is converted into an electrical signal, and the photosensitive element of the camera transmits the electrical signal to the ISP for processing, and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on image noise, brightness, and skin color. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, the ISP may be located in the camera 193 .

Camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects it to the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a complementary metal-oxide-semiconductor (complementary metal-oxide-semiconductor, CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, and then transmits the electrical signal to the ISP to convert it into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. DSP converts digital image signals into standard RGB, YUV and other image signals. In some embodiments, the mobile phone 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

Digital signal processors are used to process digital signals. In addition to digital image signals, they can also process other digital signals. For example, when the mobile phone 100 selects a frequency point, the digital signal processor is used to perform Fourier transform on the energy of the frequency point.

Video codecs are used to compress or decompress digital video. The handset 100 may support one or more video codecs. In this way, the mobile phone 100 can play or record videos in various encoding formats, such as: moving picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4 and so on.

The NPU is a neural-network (NN) computing processor. By referring to the structure of biological neural networks, such as the transfer mode between neurons in the human brain, it can quickly process input information and continuously learn by itself. Applications such as intelligent cognition of the mobile phone 100 can be implemented through the NPU, such as image recognition, face recognition, speech recognition, text understanding, and the like.

The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the memory capacity of the mobile phone 100 . The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. Such as saving music, video and other files in the external memory card.

The internal memory 121 may be used to store computer-executable program codes including instructions. The internal memory 121 may include an area for storing programs and an area for storing data. Wherein, the stored program area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.) and the like. The storage data area can store data (such as audio data, phone book, etc.) created during the use of the mobile phone 100 . In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, flash memory device, universal flash storage (universal flash storage, UFS) and the like. The processor 110 executes various functional applications and data processing of the mobile phone 100 by executing instructions stored in the internal memory 121 and/or instructions stored in a memory provided in the processor.

The mobile phone 100 can realize the audio function through the audio module 170 , the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, and the application processor. Such as music playback, recording, etc.

The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be set in the processor 110 , or some functional modules of the audio module 170 may be set in the processor 110 .

Speaker 170A, also referred to as a "horn", is used to convert audio electrical signals into sound signals. Cell phone 100 can listen to music through speaker 170A, or listen to hands-free calls.

Receiver 170B, also called "earpiece", is used to convert audio electrical signals into sound signals. When the mobile phone 100 receives a call or a voice message, the receiver 170B can be placed close to the human ear to listen to the voice.

The microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can put his mouth close to the microphone 170C to make a sound, and input the sound signal to the microphone 170C. The mobile phone 100 can be provided with at least one microphone 170C. In some other embodiments, the mobile phone 100 can be provided with two microphones 170C, which can also implement a noise reduction function in addition to collecting sound signals. In some other embodiments, the mobile phone 100 can also be provided with three, four or more microphones 170C to realize the collection of sound signals, noise reduction, identification of sound sources, and realization of directional recording functions, etc.

The earphone interface 170D is used for connecting wired earphones. The earphone interface 170D may be the USB interface 130, or a 3.5mm open mobile terminal platform (OMTP) standard interface, or a cellular telecommunications industry association of the USA (CTIA) standard interface.

The pressure sensor 180A is used to sense the pressure signal and convert the pressure signal into an electrical signal. In some embodiments, pressure sensor 180A may be disposed on display screen 194 . There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may be comprised of at least two parallel plates with conductive material. When a force is applied to the pressure sensor 180A, the capacitance between the electrodes changes. The mobile phone 100 determines the strength of the pressure based on the change in capacitance. When a touch operation acts on the display screen 194, the mobile phone 100 detects the intensity of the touch operation according to the pressure sensor 180A. The mobile phone 100 may also calculate the touched position according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities may correspond to different operation instructions. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, an instruction to view short messages is executed. When a touch operation whose intensity is greater than or equal to the first pressure threshold acts on the icon of the short message application, the instruction of creating a new short message is executed.

The gyroscope sensor 180B can be used to determine the motion posture of the mobile phone 100 .

The air pressure sensor 180C is used to measure air pressure. In some embodiments, the mobile phone 100 calculates the altitude based on the air pressure value measured by the air pressure sensor 180C to assist positioning and navigation.

The magnetic sensor 180D includes a Hall sensor. The mobile phone 100 can use the magnetic sensor 180D to detect the opening and closing of the flip holster. In some embodiments, when the mobile phone 100 is a flip phone, the mobile phone 100 can detect the opening and closing of the flip according to the magnetic sensor 180D. Furthermore, according to the detected opening and closing state of the leather case or the opening and closing state of the flip cover, features such as automatic unlocking of the flip cover are set.

The acceleration sensor 180E can detect the acceleration of the mobile phone 100 in various directions (generally three axes). When the mobile phone 100 is stationary, the magnitude and direction of gravity can be detected. It can also be used to identify the posture of electronic devices, and can be used in applications such as horizontal and vertical screen switching, pedometers, etc.

The distance sensor 180F is used to measure the distance. The mobile phone 100 can measure the distance by infrared or laser. In some embodiments, when shooting a scene, the mobile phone 100 can use the distance sensor 180F for distance measurement to achieve fast focusing.

Proximity light sensor 180G may include, for example, light emitting diodes (LEDs) and light detectors, such as photodiodes. The mobile phone 100 can use the proximity light sensor 180G to detect that the user is holding the mobile phone 100 close to the ear to make a call, so as to automatically turn off the screen to save power. The proximity light sensor 180G can also be used in leather case mode, automatic unlock and lock screen in pocket mode.

The ambient light sensor 180L is used for sensing ambient light brightness. The mobile phone 100 can adaptively adjust the brightness of the display screen 194 according to the perceived ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also cooperate with the proximity light sensor 180G to detect whether the mobile phone 100 is in the pocket to prevent accidental touch.

The fingerprint sensor 180H is used to collect fingerprints. The mobile phone 100 can use the collected fingerprint features to realize fingerprint unlocking, access to the application lock, take pictures with the fingerprint, answer calls with the fingerprint, and the like.

The temperature sensor 180J is used to detect temperature. In some embodiments, the mobile phone 100 uses the temperature detected by the temperature sensor 180J to implement a temperature processing strategy. For example, when the temperature reported by the temperature sensor 180J exceeds the threshold, the mobile phone 100 may reduce the performance of the processor located near the temperature sensor 180J, so as to reduce power consumption and implement thermal protection.

The touch sensor 180K is also called "touch device". The touch sensor 180K can be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also called a “touch screen”. The touch sensor 180K is used to detect a touch operation on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194 . In some other embodiments, the touch sensor 180K may also be disposed on the surface of the mobile phone 100 , which is different from the position of the display screen 194 .

The bone conduction sensor 180M can acquire vibration signals.

The keys 190 include a power key, a volume key and the like. The key 190 may be a mechanical key. It can also be a touch button. The mobile phone 100 can receive key input and generate key signal input related to user settings and function control of the mobile phone 100 .

The motor 191 can generate a vibrating reminder. The motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations applied to different applications (such as taking pictures, playing audio, etc.) may correspond to different vibration feedback effects. The motor 191 may also correspond to different vibration feedback effects for touch operations acting on different areas of the display screen 194 . Different application scenarios (for example: time reminder, receiving information, alarm clock, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

The indicator 192 can be an indicator light, and can be used to indicate charging status, power change, and can also be used to indicate messages, missed calls, notifications, and the like.

The SIM card interface 195 is used for connecting a SIM card. The SIM card can be connected and separated from the mobile phone 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195 .

It can be understood that the above structure shown in FIG. 13 does not constitute a specific limitation on the mobile phone 100 . In some other embodiments of the present application, the mobile phone 100 may include more or fewer components than shown in the figure, or combine certain components, or separate certain components, or arrange different components. The illustrated components can be realized in hardware, software or a combination of software and hardware.

In some other embodiments, the structure of the mobile phone 100 may also refer to the structure shown in FIG. 14 .

As shown in FIG. 14 , the mobile phone 100 includes a processor 1410 , a communication module 1420 , a memory 1430 , a display device 1440 , and an input device 1450 . Multiple application programs 1401 are installed on the operating system 1400 configured on the mobile phone 100. It can be understood that the multiple application programs 1401 include payment applications and other applications without payment functions.

Among them, the processor 1410 can control the reception and manipulation of input and output data among various components of the computer system. In the embodiment of the present application, the processor 1410 may be used to calculate and process the fund transaction data and the like involved in the receipt and payment details.

The communication module 1420 is used to connect the terminal device to the Internet and perform data communication with the server deployed on the Internet. The data interaction between the application program and the server is through the communication module. In this embodiment of the application, the communication module 1420 can be used to interact with the server, obtain the UTC time on the server, and transmit data such as consumption records.

The memory 1430 may be connected to the processor 1410, and is used for storing operating system, application program information, etc. used by the terminal. Memory may include read only memory (ROM), random access memory (RAM), etc. Information may also reside on removable storage media, including SD memory cards, and be loaded or installed on the computer system when needed. . In the embodiment of the present application, the memory is used to store consumption information and other data.

The display device 1440 may be connected to the processor 1410, and is configured to receive and display the processing result returned by the processor 1410. It is usually provided with a Graphical User Interface (GUI), which provides an easy-to-use user interface between the user of the computer system and the operating system or applications running on it. In this embodiment of the application, the display device 1440 can be used to display payment codes, consumption records and other information.

The input device 1450 may be connected to the processor 1410, and the input device 1450 is used for receiving user's input operation and sending the user's input content to the server. The input device may be a touchpad or a touch screen placed on or in front of the display device, and may be based on various sensing technologies, including but not limited to capacitive sensing, resistive sensing, surface acoustic wave sensing, pressure sensing, light sensing, and the like. The touchpad or touchscreen may be integrated with the display device or may be a separate component. The aforementioned input device 1450 may be a single-point or multi-point input device, which is not limited here.

It can be understood that for the structures and functions involved in FIG. 14 , reference may also be made to the corresponding structures and related descriptions shown in FIG. 13 above, and details will not be repeated here.

Reference to "one embodiment" or "an embodiment" in the specification means that a specific feature, structure or characteristic described in connection with the embodiment is included in at least one exemplary implementation or technology disclosed according to the present application. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

The present disclosure also relates to means for performing operations in text. This apparatus may be specially constructed for the required purposes or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored on a computer readable medium such as, but not limited to, any type of disk including floppy disk, compact disk, CD-ROM, magneto-optical disk, read-only memory (ROM), random-access memory (RAM) , EPROM, EEPROM, magnetic or optical card, application specific integrated circuit (ASIC), or any type of medium suitable for storing electronic instructions, and each may be coupled to a computer system bus. Furthermore, computers referred to in the specification may comprise a single processor or may be architectures involving multiple processors for increased computing power.

The processes and displays presented herein are not inherently related to any specific computer or other device. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform one or more method steps. The architecture for a variety of these systems is discussed in the description below. In addition, any specific programming language sufficient to implement the techniques and embodiments disclosed herein may be used. Various programming languages can be used to implement the present disclosure, as discussed herein.

Additionally, the language used in this specification has been chosen primarily for readability and instructional purposes and may not have been chosen to delineate or limit the subject matter disclosed. Accordingly, the present disclosure is intended to illustrate, not to limit, the scope of the concepts discussed herein.

Claims (16)

1. An electronic payment method applied to an electronic device on which a plurality of payment applications and payment management applications are installed, the method comprising:

the payment management application detects a first payment operation of a user in the payment management application, wherein the first payment operation indicates that a payment function is completed with a first payment application of the plurality of payment applications;

and the payment management application calls the payment function of the first payment application to complete the payment function corresponding to the first payment operation.

2. The method of claim 1, wherein the payment management application invokes a payment function of the first payment application, comprising:

the payment management application calls a payment function of the first payment application to generate a payment code, and displays the payment code in a display interface of the payment management application; or

And the payment management application calls a payment function of the first payment application to display a code scanning window in a display interface of the payment management application.

3. The method of claim 1, wherein the payment management application displays a prompt that payment for the first payment operation has been completed.

4. The method of claim 1, wherein the payment management application invokes a payment function of the first payment application, and after completing the payment function corresponding to the first payment operation, the method further comprises:

the payment management application records the generated first payment data completing the first payment operation.

5. The method of claim 1, wherein the payment management application detects that a user is prior to a first payment operation in the payment management application, the method further comprising:

presenting authorization prompt information to a user in a display interface of the payment management application or a display interface of the first application, wherein,

the authorization prompt message is used for prompting a user whether to authorize the management authority of the payment function of the first payment application to the payment management application;

and under the condition that the authorization operation of the user is detected, authorizing the management authority of the payment function of the first payment application to the payment management application, and displaying prompt information of successful authorization.

6. The method of claim 5, wherein the administrative rights include the payment management application being able to complete a payment by invoking a payment function of the first payment application, and

the payment management application is capable of obtaining first historical payment data from the first payment application.

7. The method of claim 6, further comprising:

the payment management application generating a payment record for at least one user of the electronic device based on the first and second historical payment data, wherein,

the second historical payment data is record data of payment operations completed by the payment management application calling the first payment application.

8. The method of claim 7, wherein the first historical payment data or second historical payment data comprises:

the payment operation comprises one or more of the occurrence time of the payment operation, the transaction property, the merchant name, the collection account, the merchant bill number, the payment method, the payment account and the serial number.

9. The method of claim 8, further comprising:

and generating a financing analysis report or a financing suggestion corresponding to the user based on the payment record of the user.

10. The method of claim 5, wherein the display interface of the payment management application includes an authorization management control.

11. The method of claim 10, further comprising:

after detecting the operation of the user on the authorization management control, the payment management application displays an authorized payment application and an unauthorized payment application to the user;

and under the condition that the payment management application detects that the user confirms that at least one unauthorized payment application is authorized, acquiring the management authority of the payment function of the payment application authorized by the user, and displaying prompt information of successful authorization.

12. The method of claim 10, further comprising:

and after detecting the operation of the user on the authorization management control, the payment management application deletes the payment application which the user selects to terminate the authorization.

13. The method of any of claims 1-12, wherein an operating system of the electronic device comprises a Hongmon operating system.

14. An electronic device, comprising: one or more processors; one or more memories; the one or more memories store one or more programs that, when executed by the one or more processors, cause the electronic device to perform the electronic payment method of any one of claims 1-13.

15. A computer-readable storage medium having stored thereon instructions that, when executed on a computer, cause the computer to perform the electronic payment method of any one of claims 1 to 13.

16. A computer program product comprising computer programs/instructions which, when executed by a processor, implement the electronic payment method of any one of claims 1 to 13.

Images