Smart watch aggregation code service processing

Abstract

Disclosed in embodiments of the present description is a smart watch aggregation code service processing solution, comprising: an application server receiving a service trigger instruction that is sent by a smart watch end when scanning an aggregation code displayed by a target merchant; on the basis of the service trigger instruction, sending a merchant information query request to an aggregation code service provider by calling a first SPI, such that the smart watch end obtains information of the target merchant; receiving a service execution request sent by the smart watch end on the basis of the information of the target merchant; on the basis of the service execution request, sending a corresponding merchant service order creation request to the aggregation code service provider by calling a second SPI, such that the aggregation code service provider places a corresponding order on an open platform corresponding to the application server, wherein the first SPI and the second SPI are defined by an application service provider to which the application server belongs, and are implemented by the aggregation code service provider; and receiving a merchant service order generated and returned by the open platform in response to the placement of the order, and on the basis of the merchant service order, advancing service processing to completion.

Description

Smartwatch aggregation code business processing Technical Field

[0001] This manual relates to the field of payment technology, and in particular to methods, devices, and equipment for processing smartwatch aggregated code transactions. Background Technology

[0002] With the development of internet technology and the widespread use of smartphones, more and more businesses can be conducted through smartphone applications, bringing great convenience to people's lives.

[0003] QR codes are now widely used in payment and other business sectors. Users may use different payment service providers' QR code payment services in their daily lives, resulting in different QR codes for payment. Users need to use the correct mapping between these providers' QR codes on their devices (usually the app client) to scan that provider's QR code to make a payment. Scanning a different provider's QR code with the same app may result in payment failure. Therefore, to provide convenience and error tolerance for users, aggregated QR codes have emerged. These aggregate QR code services from two or more different payment service providers. Merchants can generate their own aggregated QR codes for users to use for payment. Users can scan these aggregated QR codes using any of the payment service providers' apps to make a payment.

[0004] In one current QR code payment solution, when a payment service provider's application scans the merchant's QR code on a smartphone, the merchant's QR code H5 page will open in the application's H5 container. Users can then place orders and make payments on the QR code H5 page.

[0005] However, the above-mentioned aggregated code payment solution has problems on smartwatches. Due to the limitations of the smartwatch operating system, it is often impossible to implement in an H5 container environment, making it difficult to use this solution to realize aggregated code payment on smartwatches. Similar problems may exist for other aggregated code services on smartwatches.

[0006] Therefore, a more suitable solution for processing aggregated code business is needed for smartwatches. Summary of the Invention

[0007] This specification provides one or more embodiments of a method, apparatus, and device for processing aggregated code services on smartwatches, in order to solve the following technical problem: the need for an aggregated code service processing solution more suitable for smartwatches.

[0008] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows.

[0009] This specification provides one or more embodiments of a smartwatch aggregation code business processing method applied to a payment server. The method includes: receiving a business triggering instruction sent by the smartwatch terminal through scanning an aggregation code displayed by a target merchant; according to the business triggering instruction, sending a merchant information query request to an aggregation code service provider by calling a first SPI interface (Service Provider Interface), so that the smartwatch terminal obtains the target merchant information queried by the aggregation code service provider; receiving a business execution request sent by the smartwatch terminal based on the target merchant information; according to the business execution request, sending a corresponding merchant business order creation request to the aggregation code service provider by calling a second SPI interface, so that the aggregation code service provider places a corresponding order with the open platform corresponding to the application server, wherein the first SPI interface and the second SPI interface are interfaces defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider; receiving a merchant business order generated and returned by the open platform in response to the order, and advancing the business processing process according to the merchant business order.

[0010] This specification provides another method for processing aggregated code services on a smartwatch, applied to a smartwatch. The method includes: scanning an aggregated code displayed by a target merchant and sending a service trigger instruction to an application server, so that the application server, according to the service trigger instruction, sends a merchant information query request to an aggregated code service provider by calling a first SPI interface; obtaining the target merchant information queried by the aggregated code service provider, and sending a service execution request to the application server based on the target merchant information, so that the application server, according to the service execution request, sends a corresponding merchant business order creation request to the aggregated code service provider by calling a second SPI interface; receiving the merchant business order; and advancing the business processing process according to the merchant business order. The merchant business order is generated and returned to the aggregated code service provider by the aggregated code service provider responding to the business order creation request by placing an order with the corresponding open platform of the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but implemented by the aggregated code service provider.

[0011] This specification provides one or more embodiments of a smartwatch aggregation code business processing device, applied to a payment server. The device includes: a trigger receiving module, which receives a business trigger instruction sent by the smartwatch terminal by scanning an aggregation code displayed by a target merchant; a first invocation module, which, according to the business trigger instruction, sends a merchant information query request to an aggregation code service provider by invoking a first SPI interface, so that the smartwatch terminal obtains the target merchant information queried by the aggregation code service provider; an execution receiving module, which receives a business execution request sent by the smartwatch terminal based on the target merchant information; a second invocation module, which, according to the business execution request, sends a corresponding merchant business order creation request to the aggregation code service provider by invoking a second SPI interface, so that the aggregation code service provider places a corresponding order with the open platform corresponding to the application server, wherein the first SPI interface and the second SPI interface are interfaces defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider; and a business advancement module, which receives a merchant business order generated and returned by the open platform in response to the order, and advances the business processing process according to the merchant business order to complete the process.

[0012] This specification provides one or more embodiments of a smartwatch aggregation code business processing device, applied to a smartwatch. The device includes: a scanning trigger module, which scans the aggregation code displayed by a target merchant and sends a business trigger instruction to an application server, causing the application server to send a merchant information query request to an aggregation code service provider by calling a first SPI interface according to the business trigger instruction; and an execution request module, which obtains the target merchant information queried by the aggregation code service provider and sends a business execution request to the application server based on the target merchant information, causing the application server to send a corresponding merchant business order creation request to the aggregation code service provider by calling a second SPI interface according to the business execution request, and receives the merchant business order and completes the business processing according to the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider placing an order with the open platform corresponding to the application server in response to the business order creation request. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider.

[0013] This specification provides one or more embodiments of a smartwatch QR code aggregation service processing device, applied to a payment server. The device includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor. These instructions, when executed by the at least one processor, enable the at least one processor to: receive a service trigger instruction sent by the smartwatch terminal via scanning an aggregation code displayed by a target merchant; and, based on the service trigger instruction, send a merchant information query request to an aggregation code service provider by calling a first SPI interface, thereby enabling the smartwatch terminal to obtain the aggregation code service. The system retrieves the target merchant information from the query; receives a business execution request sent by the smartwatch based on the target merchant information; based on the business execution request, it sends a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, so that the aggregation code service provider places an order with the open platform corresponding to the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider; it receives the merchant business order generated and returned by the open platform in response to the order, and proceeds with the business processing according to the merchant business order.

[0014] This specification provides one or more embodiments of a smartwatch aggregation code service processing device, applied to a smartwatch. The device includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor. These instructions, when executed by the at least one processor, enable the at least one processor to: scan the aggregation code displayed by a target merchant, send a service trigger instruction to an application server, causing the application server to, based on the service trigger instruction, send a merchant information query request to an aggregation code service provider by calling a first SPI interface; and obtain the target merchant information queried by the aggregation code service provider. Based on the target merchant's information, a business execution request is sent to the application server. The application server, in response to this request, calls the second SPI interface to send a corresponding merchant business order creation request to the aggregation code service provider, receives the merchant business order, and proceeds with the business processing based on the order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider responding to the business order creation request and placing an order with the corresponding open platform of the application server. The first and second SPI interfaces are defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider.

[0015] The above-mentioned at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: the SPI interface is defined by the application service provider (represented by the application server) for querying and placing orders, and one or more aggregate code service providers implement these SPI interfaces accordingly. This standardizes the interaction between the application service provider and the aggregate code service provider, without relying on the H5 container. Compared with the H5 container-based solution, it has better stability and helps to improve the success rate of business. Moreover, it reduces the access cost between the application service provider and the aggregate code service provider, and also gives the aggregate code service provider better flexibility. This allows smartwatches to reliably and conveniently realize payment and other businesses based on aggregate codes even if they do not support H5 containers. Therefore, it has good applicability to smartwatches and helps to improve the user experience of smartwatches. Attached Figure Description

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

[0017] Figure 1 is a flowchart illustrating a smartwatch aggregation code service processing method provided in one or more embodiments of this specification.

[0018] Figure 2 is a flowchart illustrating a call decision scheme for a first SPI interface provided in one or more embodiments of this specification.

[0019] Figure 3 is a flowchart illustrating a dial theme interface control scheme provided by one or more embodiments of this specification.

[0020] Figure 4 is a flowchart illustrating one implementation scheme of the method in Figure 1 in an application scenario provided by one or more embodiments of this specification.

[0021] Figure 5 is a schematic diagram of some dial display content on a smartwatch in one or more embodiments of this specification.

[0022] Figure 6 is a flowchart illustrating another smartwatch aggregation code service processing method provided in one or more embodiments of this specification.

[0023] Figure 7 is a structural schematic diagram of a smartwatch aggregation code service processing device provided in one or more embodiments of this specification.

[0024] Figure 8 is a structural schematic diagram of another smartwatch aggregation code service processing device provided in one or more embodiments of this specification.

[0025] Figure 9 is a structural schematic diagram of a smartwatch aggregation code service processing device provided in one or more embodiments of this specification.

[0026] Figure 10 is a structural schematic diagram of another smartwatch aggregation code service processing device provided in one or more embodiments of this specification. Detailed Implementation

[0027] This specification provides embodiments of a method, apparatus, device, and storage medium for processing aggregated code services on smartwatches.

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

[0029] The business described in this application takes payment business as a typical example, which is the target business that users want to conduct. For ease of description, some of the following embodiments are mainly illustrated using payment business scenarios. Of course, other businesses with similar problems may also adopt the solution of this application to solve them, such as e-commerce business, event registration business, health service business, advertising business, etc.

[0030] As understood in the background section, smartwatches have more limited capabilities compared to smartphones. For example, due to the limitations of their operating systems, it's difficult to implement an H5 container environment locally on a smartwatch (smartwatch manufacturers often remove this H5 container functionality to improve operating efficiency and reduce resource consumption). Therefore, it's difficult to implement aggregated code payment solutions based on H5 containers. This easily leads to smartwatch payment failures, which in turn can result in user and payment business loss for payment service providers. This is especially true for children's smartwatches, which are often the only mobile payment device for children. If they experience a failed aggregated code payment using this device, they are very likely to leave, and it's difficult to recover them, let alone generate a second payment. This is a pity for the platform and also means that users lose the opportunity to improve the situation.

[0031] Regarding the issues mentioned in the background technology, in order to enable smartwatches to better support aggregated code payments, the applicant initially attempted the following solution: The smartwatch scans the aggregated code. Upon successful scanning, an H5 container is simultaneously opened in the cloud, loading the aggregated code link. When the smartwatch user enters an amount and clicks pay, the relevant actions are synchronized to the cloud. The cloud container can intercept the payment request and return the order information to the smartwatch to proceed with the payment. However, during testing, it was found that this solution still has problems, mainly including: the cloud container needs to adapt to various types of aggregated codes and recognize the amount input and payment UI, intercepting the corresponding actions; compatibility is not good enough, and the cost is relatively high.

[0032] To address these issues, the applicant has developed and provided in this application a more suitable solution for smartwatch-based QR code processing, such as a QR code payment solution.

[0033] Based on this overall situation, the solution proposed in this application will be further explained below.

[0034] Figure 1 is a flowchart illustrating a smartwatch aggregation code service processing method provided in one or more embodiments of this specification. The execution entity of this process may include an application server, which is the server corresponding to the smartwatch. Here, the smartwatch, at the software level, mainly refers to the software used to provide the target service (e.g., a payment application client or a mini-program, in which case the application server is the payment server). Of course, at the hardware level, it is the smartwatch itself, the mobile device.

[0035] The smartwatch described in this application has hardware modules such as a camera to support QR code scanning. Applications on the smartwatch can call these hardware modules to scan and recognize QR codes within the application.

[0036] The process in Figure 1 includes the following steps.

[0037] S102: Receives a business trigger command sent by the smartwatch by scanning the aggregation code displayed by the target merchant.

[0038] A payment aggregation code, as a type of code, can simultaneously support the same type of business across multiple different channels (and of course, it can also support multiple different types of business simultaneously). For example, a payment aggregation code can support different payment methods offered by two or more different payment service providers. When a user scans the code, the system can automatically identify which payment method should be used based on the application being scanned. Currently, aggregation codes are mainly in the form of QR codes, but they may evolve into higher-dimensional codes in the future.

[0039] Different merchants have their own unique aggregated codes, which can be pre-generated with the support of aggregated code service providers and displayed to users for scanning. Aggregated code service providers are able to maintain accurate correspondences between different aggregated codes and different merchants.

[0040] Users can scan and recognize the aggregated codes displayed by target merchants using the scanning function provided by an application client or mini-program on their smartwatches. Based on the scanning and recognition results, a business trigger command is sent to the corresponding application server.

[0041] In one or more embodiments of this specification, a service trigger instruction can be used to request and query information about the current target merchant in order to prompt the user, thereby giving the user sufficient awareness to confirm the service to be performed. The service trigger instruction may contain at least a portion of the aggregate code value, or the parsing result obtained after parsing these code values.

[0042] It should be noted that the term "merchant" in this application can be understood as a broader concept. A merchant is an entity that uses an application service provider's platform to provide services to users. In addition to merchants selling goods in common e-commerce scenarios, entities that use the platform to organize other activities for users, provide non-product services, or conduct management and assessment can also be broadly regarded as merchants from the perspective of the application service provider.

[0043] S104: According to the business triggering instruction, a merchant information query request is sent to the aggregation code service provider by calling the first SPI interface, so that the smart watch can obtain the target merchant information queried by the aggregation code service provider.

[0044] In one or more embodiments of this specification, the SPI interface mentioned in this application, i.e., the service provisioning interface, is defined at the interface level by the application service provider, but at the implementation level, it is implemented by the independent software developer or merchant cooperating with the application service provider. In the case of aggregated code, specifically, it is implemented by the aggregated code service provider. Thus, for the same SPI interface defined by the application service provider to which the application service provider belongs, different aggregated code service providers can implement it differently according to their actual needs, which has good compatibility and helps to efficiently connect more aggregated code service providers without the application service provider having to make frequent changes. Therefore, it is standardized enough from the perspective of the application service provider, shielding the user side from these differences.

[0045] The first SPI interface is primarily used to request and query information about target merchants; it serves as the merchant information query interface. The merchant information retrieved by the aggregation code service provider can be directly returned to the smartwatch by the aggregation code service provider, or indirectly returned to the smartwatch through the application server. It should be noted that there may not be a single first SPI interface; it can be a collection of multiple SPI interfaces. Each SPI interface in the collection can be responsible for a more specific function. For example, there might be a first SPI interface for initiating merchant information query requests, and another first SPI interface for returning the query results, and so on.

[0046] S106: Receive the business execution request sent by the smartwatch based on the information of the target merchant.

[0047] Based on the target merchant's information, the smartwatch displays a confirmation interface to the user. This interface indicates the specific merchant, such as their name and logo. It can also describe the merchant's services, including details like the items to be paid and the amount due. The user can then confirm the transaction on this interface (a more specific service selection function can be provided, allowing the user to choose which service to execute from several options), triggering the smartwatch to send a service execution request to the application server.

[0048] In one or more embodiments of this specification, the smartwatch may not support H5 containers, or even H5 pages. The solution presented in this application demonstrates a particular advantage over existing technologies in such cases. In this scenario, it is confirmed that the interface does not belong to a page within an H5 container, or even not to an H5 page at all.

[0049] Furthermore, considering that the application server, through the SPI interface, can shield the differences in interface implementations among different aggregate code service providers (e.g., differences in input / output parameters, data formats, field meanings, compliance requirements, and algorithms used), the confirmation interface can also be presented in a more standardized manner. In this case, the confirmation interface does not necessarily need to be a page or interface obtained from the aggregate code service provider, thus reducing the implementation cost for the aggregate code service provider and helping to avoid potential compatibility issues between the confirmation interface and the smartwatch. Simultaneously, considering the simultaneous support for both direct and indirect return of merchant information from the aggregate code service provider, the smartwatch can generate its own interface locally based on the target merchant's information, rather than obtaining a page from the application server. This allows the smartwatch to more flexibly adapt to its own capabilities to generate the confirmation interface, especially by generating a simpler page suitable for display and viewing on a smartwatch. From the application service provider's perspective, this approach offers a higher degree of standardization while also allowing for personalization, avoiding excessive restrictions imposed by the aggregate code service provider or the application server.

[0050] S108: Based on the business execution request, a corresponding merchant business order creation request is sent to the aggregation code service provider by calling the second SPI interface, so that the aggregation code service provider places an order with the open platform corresponding to the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider.

[0051] Referring to the first SPI interface described earlier, the second SPI interface can be understood similarly. The main difference between the two lies in their purpose; the second SPI interface is primarily used for creating merchant business orders.

[0052] The business execution request sent from the smartwatch can also be considered a type of order placement. Here, an order (referred to as a user order for clarity) is placed by the smartwatch user for the merchant, while a merchant business order is placed by the merchant (or executed on behalf of the aggregated code service provider) for the business service provider. The business service provider acts as a third party between the user and the merchant, providing a business platform for both parties. User orders are used for users to request business transactions, while merchant business orders are based on providing the corresponding services and requesting corresponding benefits (usually paid by the user). For example, in a payment scenario, a user order could be a payment order for a merchant service, while a merchant business order could be a merchant's cashier receipt. It can be seen that these two order placement operations correspond and are unified, essentially belonging to the same business transaction.

[0053] An open platform is a platform provided by application service providers, primarily targeting merchants or developers. In this application, it can be used for aggregated code service providers or merchants to place orders. The open platform and the application server can be different entities. Direct user interaction mainly involves the application server and rarely involves the open platform. Of course, if the corresponding functions of the open platform are integrated into the application server, aggregated code service providers can also place orders through the application server. This process may involve interaction between different modules within the application server. Alternatively, the application server can obtain the necessary information from the aggregated code service provider to generate merchant business orders for the aggregated code service provider. This method places higher demands on the application server compared to the interaction method based on the open platform.

[0054] S110: Receive the merchant business order generated and returned by the open platform in response to the order, and proceed with the business processing according to the merchant business order.

[0055] In one or more embodiments of this specification, based on a merchant's business order, the cost paid by the user (e.g., deducting the payment amount) can be obtained from the user and settled accordingly with the merchant. This is illustrated using the logic of a common payment transaction. Of course, for transactions that do not involve payment, the application server can similarly complete the transaction for both the user and the merchant based on the merchant's business order, thereby fulfilling its role as a third party.

[0056] The method shown in Figure 1 defines the SPI interface for querying and order placement through the application service provider (represented by the application server). One or more aggregate code service providers then implement these SPI interfaces. This standardizes the interaction between the application service provider and the aggregate code service provider, eliminating the need for an H5 container. Compared to H5 container-based solutions, this method offers better stability and improves business success rates. Furthermore, it reduces the access costs between the application service provider and the aggregate code service provider and provides greater flexibility to the aggregate code service provider. This allows smartwatches to reliably and conveniently implement payment and other services based on aggregate codes even if they do not support H5 containers. Therefore, it is well-suited for smartwatches and helps improve the user experience.

[0057] Based on the method in Figure 1, this specification also provides some specific implementation schemes and extension schemes of the method, which will be further explained below.

[0058] Based on the principle of the above scheme, one or more embodiments of this specification provide a flowchart of a call decision scheme for a first SPI interface, as shown in Figure 2.

[0059] The process shown in Figure 2 includes the following steps.

[0060] S202: After receiving the service trigger instruction sent by the smartwatch, determine whether the smartwatch supports H5 containers based on the service trigger instruction.

[0061] If H5 containers are not supported, the SPI interface-based solution should be prioritized. However, if H5 containers are supported, a solution based on H5 containers and business interception can be considered.

[0062] To facilitate judgment, the service trigger command can include the smartwatch's capability information. Of course, if the type of sending device can be determined from the service trigger command, a simpler judgment can be made, which is more efficient. For example, based on the service trigger command, it can be determined whether the sending device is a smartwatch or a smartphone; if it is a smartwatch, then proceed with the subsequent steps.

[0063] S204: If not, then according to the business triggering instruction, by calling the first SPI interface, a merchant information query request carrying the code value of the aggregation code and the identifier of the smartwatch is sent to the aggregation code service provider, so that the aggregation code service provider can query the information of the target merchant according to the code value of the aggregation code, and return the information of the target merchant to the smartwatch according to the identifier of the smartwatch.

[0064] If the aggregated code service provider indirectly returns the target merchant's information to the smartwatch through the application server, then the merchant information query request does not need to carry the smartwatch's identifier.

[0065] In cases where smartwatches do not support H5 containers or even H5 interfaces, this application considers not using a separate additional page for the confirmation interface, but rather utilizing the watch face theme (at least including the smartwatch's desktop) for presentation. This approach can clearly and unobtrusively prompt the user, facilitate the persistent accumulation and dynamic display of the user's business activities over a period of time, and eliminate the need to enter specific business applications, thus minimizing the processing resources required.

[0066] Based on this idea, one or more embodiments of this specification provide a flowchart of a dial theme interface control scheme, as shown in Figure 3.

[0067] The process shown in Figure 3 includes the following steps.

[0068] S302: Define dial theme feature parameters in advance for the first SPI interface. The dial theme feature parameters are used by the aggregation code service provider to assign values ​​according to the queried merchant information. The information of the target merchant is represented by the assigned dial theme feature parameters and returned to the smart watch through the first SPI interface (either directly returned by the aggregation code service provider or indirectly returned by the application server).

[0069] The dial theme features can include, for example, control layout, desktop, style, icons, and text. Different dial theme features can be assigned to different merchants based on their information. After assignment, these features can reflect the merchant's and / or current business activities from one or more of the above parameters, allowing users to understand them intuitively.

[0070] S304: Receive a business execution request sent by the smartwatch in response to a confirmation operation performed on a temporary watch face theme interface that serves as the confirmation interface, wherein the temporary watch face theme interface is generated based on the assigned watch face theme feature parameters and is automatically switched from the default watch face theme interface.

[0071] In one or more embodiments of this specification, the default watch face theme can be the watch face theme used by the smartwatch when scanning the aggregation code displayed by the target merchant. After switching, the user can clearly perceive that they are currently interacting with the corresponding merchant's service and can more clearly understand which merchant it is, which also helps to promote the merchant. In this case, the user can remain on the desktop on the smartwatch without displaying a separate page over the desktop, consuming few resources and not affecting the user's ability to perform other operations. The temporary watch face theme can include controls for performing confirmation operations, such as an icon on the desktop, or even directly use physical buttons or knobs on the smartwatch as confirmation buttons or knobs.

[0072] S306: After the merchant's business order processing is completed, a watch face theme restoration command is sent to the smartwatch so that the smartwatch switches back from the temporary watch face theme to the default watch face theme.

[0073] Similarly, smartwatches can automatically switch and restore the watch face theme without requiring the application server to trigger it.

[0074] In one or more embodiments of this specification, the default watch face theme can be dynamically updated based on the user's business interactions with different merchants on the smartwatch, simultaneously displaying (for example, displaying all merchants involved on a daily basis) the information of these merchants. In this way, the default watch face theme itself is equivalent to a cumulative record poster of merchant interactions, continuously displayed on the smartwatch for easy viewing. Moreover, this continuity does not consume additional processing resources, increasing the actual value of the watch face theme for the user.

[0075] In this case, the default watch face theme interface switched back to in step S306 can be obtained by updating the previous default watch face theme interface based on the temporary watch face theme interface (adding the current merchant's information).

[0076] Furthermore, for the default watch face theme interface that is dynamically updated based on merchant information, users can choose different modes to present it as needed. For example, if users are more concerned about the amount of information, they can use the "information mode" to present it in a way that more clearly reflects the merchant information involved. If users are more concerned about aesthetics, they can use the "artistic mode" to present it. In this case, the merchant information can be blurred and artistically processed before presentation. The intuitiveness will be reduced, but it may be more aesthetically pleasing.

[0077] In addition, even after the business is completed, users can continue to use the temporary watch face theme interface as needed, without having to switch back.

[0078] Based on the above description, for ease of understanding, taking the application scenario of payment business as an example, one or more embodiments of this specification provide a flowchart of an implementation scheme of the method in Figure 1 in this scenario, see Figure 4.

[0079] In this scenario, the application server mentioned above is specifically a payment server (the application is specifically a payment application), the smartwatch is specifically a payment client, the application service provider is specifically a payment service provider, the business execution request is specifically a payment request, and the merchant business order is specifically a merchant cash register order.

[0080] For the scheme shown in Figure 4, preliminary preparations are required. This includes defining two SPI interfaces, one for querying merchant information and the other for creating merchant payment slips in the aggregated code scenario. These two interfaces are implemented by the aggregated code service provider, serving as the first and second SPI interfaces mentioned above. The entire process is also primarily divided based on the tasks involved in these two interfaces.

[0081] Regarding merchant information retrieval, the main logic includes: the user opens the payment client on their smartwatch and scans the QR code displayed by the merchant; subsequently, the payment server calls the first SPI interface to transmit the merchant's QR code value and other relevant information to the QR code service provider; the QR code service provider then uses this information to query the merchant information behind the code, such as the merchant name, merchant logo, merchant ID, and payment amount, and then sends this information back to the payment client through the first SPI interface; after receiving this information, the payment client renders and displays a confirmation interface corresponding to that merchant, allowing the user to confirm and verify the merchant information, and then confirm after confirming that it is correct.

[0082] Regarding merchant payment slips in the context of QR code aggregation, the main logic includes: the user clicks "confirm" on the confirmation screen corresponding to the merchant; subsequently, the payment server calls the second SPI interface to transmit information such as the payment user and payment amount to the QR code aggregation service provider; the QR code aggregation service provider can then place an order on the payment service provider's open platform based on this information, obtain the merchant payment slip, and after the order is placed, send the order number and other relevant information back to the payment server through the second SPI interface; after receiving the order information, the payment server can initiate and complete the payment.

[0083] Intuitively, one or more embodiments of this specification provide another application scenario, in which the solution in Figure 4 involves some dial display content of a smartwatch, as shown in Figure 5.

[0084] Figure 5 contains five sub-images, arranged from left to right and top to bottom. The first sub-image prompts the user to scan a QR code. Assuming the user scans a merchant's aggregated code, a confirmation interface is then rendered locally, as shown in the second sub-image. This is a simplified page for smartwatches, not an H5 page within an H5 container. It might include, for example, the merchant's name, "XX Grocery Store." Clicking the "Pay to" button leads to the third sub-image, which shows the option to manually specify the payment amount. After confirming the payment amount, the user proceeds to the fourth sub-image, where they can click the "Confirm Payment" button to place the order and initiate payment. Once the payment process is complete, the user is prompted in the fifth sub-image that the payment was successful. The entire display process and content are clear and concise, consume minimal resources, are user-friendly for smartwatches, and are easy for users to understand and operate.

[0085] The solution shown in Figure 4, based on the SPI interface defined for querying merchant information and creating aggregated payment orders and implemented by the aggregated code service provider, avoids compatibility issues while effectively improving the stability and success rate of aggregated code payments. Compared to aggregated code payment solutions based on H5 containers, it offers better stability and a higher payment success rate, which is beneficial for aggregated code service providers and helps retain more users, especially children's smartwatch users.

[0086] The preceding description is mainly from the perspective of the application server. Based on the same idea, one or more embodiments of this specification also provide another method for processing smartwatch aggregation codes, which is described from the perspective of the smartwatch. Figure 6 is a flowchart of this other method.

[0087] The process shown in Figure 6 includes the following steps.

[0088] S602: By scanning the aggregation code displayed by the target merchant, a business trigger instruction is sent to the application server, so that the application server sends a merchant information query request to the aggregation code service provider by calling the first SPI interface according to the business trigger instruction.

[0089] S604: Obtain the target merchant information queried by the aggregation code service provider, and send a business execution request to the application server based on the target merchant information. This allows the application server to send a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, and to receive the merchant business order. The application server then proceeds with the business processing based on the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider placing an order with the open platform corresponding to the application server in response to the business order creation request. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider.

[0090] For details, please refer to the previous explanation; further details will not be repeated here.

[0091] Based on the same approach, one or more embodiments of this specification also provide apparatus and devices corresponding to the above-described methods, as shown in Figures 7 to 10. The apparatus and devices are capable of executing the above-described methods and related optional solutions accordingly.

[0092] Trigger receiving module 702 receives a business trigger instruction sent by the smartwatch terminal through scanning the aggregation code displayed by the target merchant; first calling module 704, according to the business trigger instruction, sends a merchant information query request to the aggregation code service provider by calling the first SPI interface, so that the smartwatch terminal obtains the target merchant information queried by the aggregation code service provider; execution receiving module 706 receives a business execution request sent by the smartwatch terminal based on the target merchant information; second calling module 708, according to the business execution request, sends a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, so that the aggregation code service provider places a corresponding order with the open platform corresponding to the application server, wherein the first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider; business advancement module 710 receives the merchant business order generated and returned by the open platform in response to the order, and advances the business processing process according to the merchant business order to complete the process.

[0093] Optionally, the first calling module 704 sends a merchant information query request carrying the code value of the aggregation code and the identifier of the smartwatch to the aggregation code service provider, so that the aggregation code service provider can query the information of the target merchant based on the code value of the aggregation code, and return the information of the target merchant to the smartwatch based on the identifier of the smartwatch.

[0094] Optionally, before sending a merchant information query request to the aggregation code service provider by calling the first SPI interface according to the business trigger instruction, the first calling module 704 determines whether the smartwatch supports the H5 container according to the business trigger instruction, and determines that the result of the determination is no.

[0095] Optionally, the execution receiving module 706 receives a business execution request sent by the smartwatch in response to a confirmation operation performed on the confirmation interface; wherein the confirmation interface is not a page in an H5 container.

[0096] Optionally, the confirmation interface is a locally generated interface by the smartwatch based on the information of the target merchant, rather than a page obtained from the aggregation code service provider or the application server.

[0097] Optionally, the first SPI interface defines a watch face theme feature parameter, which is used by the aggregation code service provider to assign values ​​based on the queried merchant information. The information of the target merchant is represented by the assigned watch face theme feature parameter and returned to the smartwatch through the first SPI interface. The execution receiving module 706 receives a business execution request sent by the smartwatch in response to a confirmation operation performed on a temporary watch face theme interface that serves as the confirmation interface. The temporary watch face theme interface is generated based on the assigned watch face theme feature parameter and is automatically switched from the default watch face theme interface.

[0098] Optionally, after the merchant business order processing is completed, the business promotion module 710 sends a watch face theme interface restoration command to the smartwatch so that the smartwatch switches back from the temporary watch face theme interface to the default watch face theme interface.

[0099] Optionally, the open platform is a platform provided by the application service provider for placing orders by the aggregation code service provider or merchant. The open platform and the application server are different entities.

[0100] Optionally, the application server includes a payment server, the application service provider includes a payment service provider, the business execution request includes a payment request, and the merchant business order includes a merchant cash register order.

[0101] Figure 8 is a schematic diagram of another smartwatch aggregation code service processing device provided in one or more embodiments of this specification. The device is applied to a smartwatch and includes: a scan trigger module 802, which scans the aggregation code displayed by the target merchant and sends a service trigger instruction to an application server, so that the application server sends a merchant information query request to the aggregation code service provider by calling a first SPI interface according to the service trigger instruction; and an execution request module 804, which obtains the information of the target merchant queried by the aggregation code service provider and sends a service execution request to the application server according to the information of the target merchant. The application server, based on the business execution request, sends a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, and receives the merchant business order, and completes the business processing according to the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider responding to the business order creation request by placing an order with the open platform corresponding to the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider.

[0102] Figure 9 is a schematic diagram of the structure of a smartwatch aggregation code business processing device provided in one or more embodiments of this specification. The device is applied to a payment server and includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor. These instructions, when executed by the at least one processor, enable the at least one processor to perform the following: receiving a business trigger instruction sent by the smartwatch terminal through scanning an aggregation code displayed by a target merchant; and, according to the business trigger instruction, sending a merchant information query request to the aggregation code service provider by calling a first SPI interface, so that the smartwatch terminal obtains... The aggregation code service provider retrieves the target merchant's information; receives a business execution request sent by the smartwatch based on the target merchant's information; based on the business execution request, sends a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, so that the aggregation code service provider places an order with the open platform corresponding to the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider; receives the merchant business order generated and returned by the open platform in response to the order, and completes the business processing according to the merchant business order.

[0103] Figure 10 is a schematic diagram of another smartwatch aggregation code business processing device provided in one or more embodiments of this specification. The device is applied to a smartwatch and includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor. These instructions, when executed by the at least one processor, enable the at least one processor to: scan the aggregation code displayed by the target merchant, send a business trigger instruction to an application server, and cause the application server to send a merchant information query request to the aggregation code service provider by calling a first SPI interface according to the business trigger instruction; and obtain the merchant information queried by the aggregation code service provider. The system retrieves information about the target merchant and, based on this information, sends a business execution request to the application server. The application server, in response to the business execution request, calls the second SPI interface to send a corresponding merchant business order creation request to the aggregation code service provider, receives the merchant business order, and proceeds with the business processing based on the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider responding to the business order creation request and placing an order with the corresponding open platform of the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider.

[0104] Based on the same approach, one or more embodiments of this specification also provide a non-volatile computer storage medium applied to a payment server. The medium stores computer-executable instructions configured to: receive a business trigger instruction sent by a smartwatch by scanning an aggregated code displayed by a target merchant; according to the business trigger instruction, send a merchant information query request to an aggregated code service provider by calling a first SPI interface, so that the smartwatch obtains the target merchant information queried by the aggregated code service provider; receive a business execution request sent by the smartwatch based on the target merchant information; according to the business execution request, send a corresponding merchant business order creation request to the aggregated code service provider by calling a second SPI interface, so that the aggregated code service provider places a corresponding order with the open platform corresponding to the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but implemented by the aggregated code service provider; receive a merchant business order generated and returned by the open platform in response to the order, and proceed with the business processing according to the merchant business order.

[0105] This specification also provides another non-volatile computer storage medium for use in smartwatches, wherein the medium stores computer-executable instructions configured to: scan the aggregation code displayed by a target merchant, send a business trigger instruction to an application server, causing the application server to send a merchant information query request to an aggregation code service provider by calling a first SPI interface according to the business trigger instruction; obtain the target merchant information queried by the aggregation code service provider, and send a business execution request to the application server according to the target merchant information, causing the application server to send a corresponding merchant business order creation request to the aggregation code service provider by calling a second SPI interface according to the business execution request; receive the merchant business order, and complete the business processing according to the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider placing an order with the corresponding open platform of the application server in response to the business order creation request. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider.

[0106] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0107] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0108] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0109] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0110] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0111] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0112] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0113] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0114] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0115] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0116] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0117] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0118] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0119] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0120] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0121] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for processing aggregated code services on a smartwatch, applied to an application server, the method comprising: Receive business trigger commands sent by the smartwatch by scanning the aggregation code displayed by the target merchant; According to the business triggering instruction, a merchant information query request is sent to the aggregation code service provider by calling the first SPI interface, so that the smart watch can obtain the target merchant information queried by the aggregation code service provider; Receive a business execution request sent by the smartwatch based on the information of the target merchant; According to the business execution request, the corresponding merchant business order creation request is sent to the aggregation code service provider by calling the second SPI interface, so that the aggregation code service provider places the corresponding order to the open platform of the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider. The system receives the merchant business order generated and returned by the open platform in response to the order, and proceeds with the business processing according to the merchant business order.

2. The method as described in claim 1, wherein sending a merchant information query request to the aggregation code service provider so that the smartwatch obtains the target merchant information queried by the aggregation code service provider, specifically includes: A merchant information query request carrying the code value of the aggregation code and the identifier of the smartwatch is sent to the aggregation code service provider, so that the aggregation code service provider can query the information of the target merchant based on the code value of the aggregation code, and return the information of the target merchant to the smartwatch based on the identifier of the smartwatch.

3. The method as described in claim 1, wherein before sending a merchant information query request to the aggregation code service provider by calling the first SPI interface according to the business trigger instruction, the method further includes: Based on the business trigger instruction, determine whether the smartwatch supports H5 containers, and confirm that the result of the determination is no.

4. The method as described in claim 1, wherein receiving the business execution request sent by the smartwatch terminal based on the target merchant's information specifically includes: Receive the business execution request sent by the smartwatch in response to the confirmation operation performed on the confirmation interface; The confirmation interface is not a page within the H5 container.

5. The method as described in claim 4, wherein the confirmation interface is an interface generated locally by the smartwatch based on the information of the target merchant, rather than a page obtained from the aggregation code service provider or the application server.

6. The method as described in claim 4 or 5, wherein the first SPI interface defines a dial theme feature parameter, the dial theme feature parameter is used by the aggregation code service provider to assign a value according to the queried merchant information, and the information of the target merchant is represented by the assigned dial theme feature parameter, and is returned to the smartwatch through the first SPI interface; The process of receiving the business execution request sent by the smartwatch based on the target merchant's information specifically includes: The system receives a business execution request sent by the smartwatch in response to a confirmation operation performed on a temporary watch face theme interface, which serves as the confirmation interface. The temporary watch face theme interface is generated based on the assigned watch face theme feature parameters and is automatically switched from the default watch face theme interface.

7. The method as described in claim 6, wherein after the merchant business order processing is completed, the method further includes: Send a command to the smartwatch to restore the watch face theme, so that the smartwatch switches back from the temporary watch face theme to the default watch face theme.

8. The method as described in claim 1, wherein the open platform is a platform provided by the application service provider for placing orders by the aggregation code service provider or merchant, and the open platform and the application server are different entities.

9. The method as described in claim 1, wherein the application server includes a payment server, the application service provider includes a payment service provider, the business execution request includes a payment request, and the merchant business order includes a merchant cash register order.

10. A method for processing aggregated code services on a smartwatch, applied to a smartwatch, the method comprising: By scanning the aggregation code displayed by the target merchant, a business triggering instruction is sent to the application server, so that the application server, according to the business triggering instruction, sends a merchant information query request to the aggregation code service provider by calling the first SPI interface; The system obtains the target merchant information queried by the aggregation code service provider and sends a business execution request to the application server based on the target merchant information. The application server then, based on the business execution request, sends a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, receives the merchant business order, and completes the business processing according to the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider responding to the business order creation request and placing an order with the corresponding open platform of the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider.

11. A smartwatch QR code aggregation service processing device, applied to a payment server, the device comprising: The trigger receiving module receives business trigger commands sent by the smartwatch by scanning the aggregation code displayed by the target merchant; The first calling module, according to the business triggering instruction, sends a merchant information query request to the aggregation code service provider by calling the first SPI interface, so that the smart watch can obtain the target merchant information queried by the aggregation code service provider; The execution receiving module receives a business execution request sent by the smartwatch based on the information of the target merchant. The second calling module, based on the business execution request, sends a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, so that the aggregation code service provider places an order with the open platform corresponding to the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider. The business promotion module receives the merchant business order generated and returned by the open platform in response to the order, and promotes the business processing process to completion according to the merchant business order.

12. The apparatus of claim 11, wherein the first calling module sends a merchant information query request carrying the code value of the aggregation code and the identifier of the smartwatch to the aggregation code service provider, so that the aggregation code service provider can query the information of the target merchant based on the code value of the aggregation code, and return the information of the target merchant to the smartwatch based on the identifier of the smartwatch.

13. The apparatus of claim 11, wherein the first calling module, before sending a merchant information query request to the aggregation code service provider by calling the first SPI interface according to the business triggering instruction, determines whether the smartwatch supports the H5 container according to the business triggering instruction, and determines that the result of the determination is no.

14. The apparatus of claim 11, wherein the execution receiving module receives a business execution request sent by the smartwatch in response to a confirmation operation performed on the confirmation interface; in, The confirmation interface is not a page within the H5 container.

15. The apparatus of claim 14, wherein the confirmation interface is an interface generated locally by the smartwatch based on the information of the target merchant, rather than a page obtained from the aggregation code service provider or the application server.

16. The apparatus of claim 14 or 15, wherein the first SPI interface defines a dial theme feature parameter, the dial theme feature parameter being used by the aggregation code service provider to assign a value based on the queried merchant information, and the information of the target merchant is represented by the assigned dial theme feature parameter and returned to the smartwatch through the first SPI interface; The execution receiving module receives a business execution request sent by the smartwatch in response to a confirmation operation performed on the temporary watch face theme interface, which serves as the confirmation interface. The temporary watch face theme is generated based on the assigned watch face theme feature parameters and is automatically switched from the default watch face theme for use.

17. The apparatus of claim 16, wherein after the merchant business order processing is completed, the business promotion module sends a watch face theme interface restoration command to the smartwatch terminal, so that the smartwatch terminal switches from the temporary watch face theme interface back to the default watch face theme interface.

18. The apparatus of claim 11, wherein the open platform is a platform provided by the application service provider for placing orders by the aggregation code service provider or merchant, and the open platform and the application server are different entities.

19. The apparatus of claim 11, wherein the application server includes a payment server, the application service provider includes a payment service provider, the business execution request includes a payment request, and the merchant business order includes a merchant cash register order.

20. A smartwatch aggregation code service processing device, applied to a smartwatch, the device comprising: The scanning trigger module sends a business trigger instruction to the application server by scanning the aggregation code displayed by the target merchant, so that the application server sends a merchant information query request to the aggregation code service provider by calling the first SPI interface according to the business trigger instruction. The execution request module obtains the target merchant information queried by the aggregation code service provider, and sends a business execution request to the application server based on the target merchant information. This allows the application server to send a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, and to receive the merchant business order. The application server then proceeds with the business processing based on the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider responding to the business order creation request and placing an order with the corresponding open platform of the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider.

21. A smartwatch QR code aggregation service processing device, applied to a payment server, the device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Receive business trigger commands sent by the smartwatch by scanning the aggregation code displayed by the target merchant; According to the business triggering instruction, a merchant information query request is sent to the aggregation code service provider by calling the first SPI interface, so that the smart watch can obtain the target merchant information queried by the aggregation code service provider; Receive a business execution request sent by the smartwatch based on the information of the target merchant; According to the business execution request, the corresponding merchant business order creation request is sent to the aggregation code service provider by calling the second SPI interface, so that the aggregation code service provider places the corresponding order to the open platform of the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but are implemented by the aggregation code service provider. The system receives the merchant business order generated and returned by the open platform in response to the order, and proceeds with the business processing according to the merchant business order.

22. A smartwatch aggregation code service processing device, applied to a smartwatch, the device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: By scanning the aggregation code displayed by the target merchant, a business triggering instruction is sent to the application server, so that the application server, according to the business triggering instruction, sends a merchant information query request to the aggregation code service provider by calling the first SPI interface; The system obtains the target merchant information queried by the aggregation code service provider and sends a business execution request to the application server based on the target merchant information. The application server then, based on the business execution request, sends a corresponding merchant business order creation request to the aggregation code service provider by calling the second SPI interface, receives the merchant business order, and completes the business processing according to the merchant business order. The merchant business order is generated and returned to the aggregation code service provider by the aggregation code service provider responding to the business order creation request and placing an order with the corresponding open platform of the application server. The first SPI interface and the second SPI interface are defined by the application service provider to which the application server belongs, but implemented by the aggregation code service provider.

Images