Payment processing methods, devices, equipment, and POS equipment in Android scenarios

Abstract

The embodiment of this specification discloses a payment service processing method in an Android scenario. Applied to a system including a cash register device and a payment capability expansion device, the method includes: on the cash register device, through an external software module provided by a service provider of the payment capability expansion device, detecting the location data of the user's interaction in the service page of the cash register device's own software module, judging whether the user has triggered a target service in the service page according to the location data; if so, interacting with the payment capability expansion device through the external software module so that the payment capability expansion device obtains capability requirement data adapted to its service provider; on the payment capability expansion device, executing the corresponding target service according to the capability requirement data, and returning the execution result data to the cash register device.

Description

Technical Field

[0001] The present invention relates to the field of near field communication technology, and in particular to payment service processing methods, devices, equipment and cash register equipment in Android scenarios. Background Art

[0002] Near Field Communication (NFC) is a short-range, high-frequency radio technology that operates at a frequency of 13.56MHz within a distance of 20cm. It is an integration of contactless radio frequency identification (RFID) and interconnection technology, providing a very safe and fast communication method for various electronic products.

[0003] With the popularization of NFC-enabled smartphones, NFC technology is also being used more in the payment field. For example, merchants deploy NFC payment devices at checkout counters, and users can make payments through NFC-enabled mobile phones by interacting with NFC payment devices, which is very convenient.

[0004] At present, NFC payment devices and corresponding payment applications are provided by specialized payment service providers, while merchants usually have deployed cash register devices and cash register software used on cash register devices provided by other service providers at the cash register counter, mainly Software as a Service (SaaS) cash register software, and many cash register software operating systems use Android. In this case, if merchants want to use the NFC payment devices provided by payment service providers normally to obtain the corresponding NFC payment support capabilities, they need to develop access so that the cash register devices and their cash register software can be normally connected with the NFC payment devices and their payment applications. In this case, merchants or service providers of cash register equipment and their cash register software (collectively referred to as customers from the perspective of payment service providers) need to integrate software development kits (SDKs) and develop codes to call and process corresponding interface logic. Customers are involved in development, testing, deployment and other processes, and the overall cycle is relatively long (usually weeks or even months). Moreover, since most cash register software technology stacks are old and have poor maintainability, code changes may trigger many online problems. Not only that, in actual applications, there are many types of cash register equipment and their cash register software, involving different service providers. As NFC payment devices are promoted and rolled out, the total development and access costs of many customers will be higher.

[0005] Not only NFC payment devices, but also other less traditional payment devices such as face-scanning payment devices and palm-scanning payment devices have similar problems. These devices are collectively referred to as payment capability extension devices.

[0006] Based on this, for merchants' cash register devices and cash register software in Android scenarios, there needs to be a more user-friendly solution that can expand their access to payment capability expansion devices such as NFC payment devices, so that they can obtain capabilities such as NFC payment support capabilities. Summary of the invention

[0007] One or more embodiments of the present specification provide payment service processing methods, devices, equipment and cash register equipment in Android scenarios to solve the following technical problems: For merchants' cash register equipment and cash register software in Android scenarios, there needs to be a more user-friendly solution that can expand access to payment capability expansion devices such as NFC payment devices, so that they can obtain capabilities such as NFC payment support capabilities.

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

[0009] One or more embodiments of this specification provide a payment service processing method in an Android scenario, which is applied to a system including a cash register device and a payment capability expansion device, and the method includes:

[0010] On the cash register device based on the Android operating system, an external software module provided by the service provider of the payment capability extension device is used to monitor an accessibility service event issued by the Android operating system, and based on the accessibility service event, it is determined whether the user has triggered a target service in a service page of the own software module of the cash register device;

[0011] If yes, interacting with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0012] On the payment capability expansion device, the corresponding target business is executed according to the capability requirement data, and the execution result data is returned to the cash register device.

[0013] One or more embodiments of this specification provide a payment service processing method in an Android scenario, which is applied to an external software module provided by a service provider of a payment capability expansion device, and the external software module is pre-deployed on a cash register device. The method includes:

[0014] On the cash register device based on the Android operating system, monitoring an accessibility service event issued by the Android operating system, and judging whether the user has triggered a target service in a service page of a proprietary software module of the cash register device according to the accessibility service event;

[0015] If so, the payment capability extension device interacts with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider and executes the corresponding target business according to the capability requirement data.

[0016] One or more embodiments of this specification provide a payment service processing device in an Android scenario, which is applied to a system including a cash register device and a payment capability expansion device, and the device includes:

[0017] A service trigger detection module, on the cash register device based on the Android operating system, monitors the accessibility service events issued by the Android operating system through an external software module provided by the service provider of the payment capability extension device, and determines whether the user has triggered the target service in the service page of the own software module of the cash register device according to the accessibility service events;

[0018] The adaptation capability requirement module, if yes, interacts with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0019] The target business interactive execution module executes the corresponding target business according to the capability requirement data on the payment capability extension device, and returns the execution result data to the cash register device.

[0020] One or more embodiments of this specification provide a payment service processing device in an Android scenario, which is applied to an external software module provided by a service provider of a payment capability expansion device, and the external software module is pre-deployed on a cash register device, and the device includes:

[0021] A monitoring and judging module, on the cash register device based on the Android operating system, monitors the accessibility service events issued by the Android operating system, and judges whether the user has triggered the target service in the service page of the own software module of the cash register device according to the accessibility service events;

[0022] The interaction module, if yes, interacts with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider and executes the corresponding target business according to the capability requirement data.

[0023] One or more embodiments of this specification provide a cash register device, including a proprietary software module and an external software module provided by a service provider of the payment capability expansion device;

[0024] The self-owned software module provides a business page to the user so that the user can interact in the business page;

[0025] The external software module monitors the accessibility service event issued by the Android operating system on the cash register device based on the Android operating system, and determines whether the user triggers the target service in the service page of the own software module of the cash register device according to the accessibility service event;

[0026] If yes, interact with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0027] The self-owned software module receives the execution result data returned by the payment capability expansion device and obtained by executing the corresponding target business according to the capability requirement data.

[0028] One or more embodiments of this specification provide a payment service processing device in an Android scenario, which is applied to a system including a cash register device and a payment capability expansion device. The payment service processing device in the Android scenario includes:

[0029] at least one processor; and,

[0030] a memory communicatively connected to the at least one processor; wherein,

[0031] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute:

[0032] On the cash register device based on the Android operating system, an external software module provided by the service provider of the payment capability extension device is used to monitor an accessibility service event issued by the Android operating system, and based on the accessibility service event, it is determined whether the user has triggered a target service in a service page of the own software module of the cash register device;

[0033] If yes, interacting with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0034] On the payment capability expansion device, the corresponding target business is executed according to the capability requirement data, and the execution result data is returned to the cash register device.

[0035] One or more embodiments of this specification provide a payment service processing device in an Android scenario, which is applied to an external software module provided by a service provider of a payment capability expansion device, and the external software module is pre-deployed on a cash register device. The payment service processing device in the Android scenario includes:

[0036] at least one processor; and,

[0037] a memory communicatively connected to the at least one processor; wherein,

[0038] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute:

[0039] On the cash register device based on the Android operating system, monitoring an accessibility service event issued by the Android operating system, and judging whether the user has triggered a target service in a service page of a proprietary software module of the cash register device according to the accessibility service event;

[0040] If so, the payment capability extension device interacts with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider and executes the corresponding target business according to the capability requirement data.

[0041] At least one of the above technical solutions adopted in one or more embodiments of the present specification can achieve the following beneficial effects: for the payment service provider of the payment capability expansion device, there is no need for its customers (such as merchants, cashier service providers, etc.) to develop and transform the cashier device and its own software modules (such as SaaS cashier applications), integrate software development kit processing interfaces, etc., but simply deploy the external software module provided by the payment service provider on the cashier device, connect the cashier device and the payment capability expansion device through methods such as serial ports, and then conveniently access the corresponding extended payment support capabilities. The own software module does not need to make cumbersome interface calls for the payment capability expansion device (such as NFC payment devices), and does not need to cooperate with the external software module for additional development, but is handled by the external software module. The software module actively monitors the accessibility service events sent by the Android operating system of the cash register device, and infers whether there is an opportunity for the payment capability expansion device to play a role based on the accessibility service events, without adopting more cumbersome means such as coordinate position detection and screenshot analysis. If it is inferred that there is an opportunity, it will generate capability demand data (for example, interface call data) accordingly, and interact with the payment capability expansion device instead of its own software module, so as to help the cash register device and its own software module to realize the use of extended payment support capabilities. It can be seen that this solution is mainly transformed and deployed by the payment service provider itself. Customers can easily expand access to payment capability expansion devices without development and modification. It is more user-friendly and also helps payment service providers to more widely expand extended payment services such as NFC payment services. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0043] Figure 1 A flowchart of a payment service processing method in an Android scenario provided by one or more embodiments of this specification;

[0044] Figure 2 A schematic flow chart of a labeling model preprocessing solution provided for one or more embodiments of this specification;

[0045] Figure 3 A flowchart of a capability requirement data processing solution provided for one or more embodiments of this specification;

[0046] Figure 4 A flowchart of a specific implementation scheme of a payment service processing method in an Android scenario provided by one or more embodiments of this specification;

[0047] Figure 5 A schematic diagram of a process flow of a page layout patch processing solution provided for one or more embodiments of this specification;

[0048] Figure 6 A flowchart of another payment service processing method in an Android scenario provided for one or more embodiments of this specification;

[0049] Figure 7 A schematic diagram of the structure of a payment service processing device in an Android scenario provided by one or more embodiments of this specification;

[0050] Figure 8 A schematic diagram of the structure of another payment service processing device in an Android scenario provided by one or more embodiments of this specification;

[0051] Fig. 9 A schematic diagram of the structure of a cash register device provided for one or more embodiments of this specification;

[0052] Fig.10 A schematic diagram of the structure of a payment service processing device in an Android scenario provided in one or more embodiments of this specification;

[0053] Fig.11 A schematic diagram of the structure of another payment service processing device in an Android scenario provided for one or more embodiments of this specification. DETAILED DESCRIPTION

[0054] The embodiments of this specification provide a payment service processing method, apparatus, device, storage medium, and cash register device in an Android scenario.

[0055] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0056] In response to the problems mentioned in the background technology, this application considers that the service provider of the payment capability expansion device, called the payment service provider, takes the initiative to detect the cash register device and its cash register software, flexibly and cleverly using the accessibility assistance services provided by the Android operating system, as well as the decision model created based on pre-processing work such as page area marking (used to understand some key areas in the business page of the cash register software), so as to try to instantly discover the demand for the use of the payment capability expansion device without the need for the cash register software to cooperate with development work such as interface modification. If the demand for the use of the payment capability expansion device is discovered, the payment service provider will still generate interface call data based on the decision results to help the cash register device and its cash register software use the capabilities of the payment capability expansion device, so that merchants can conveniently and efficiently access the payment capability expansion device, and there is almost no need for the merchants to pay any modification costs.

[0057] Based on this general idea, the solution of this application will be further described below.

[0058] Figure 1 A flowchart of a payment service processing method in an Android scenario provided in one or more embodiments of this specification is provided. The method is applied to a system including a cash register device (the operating system used is an Android operating system) and a payment capability expansion device. In the system, the cash register device and the payment capability expansion device are connected by wire or wireless means, and the payment capability expansion device service assists the cash register device in working. The execution subject of the process can be the entire system, and the specific steps can be executed by the corresponding software and hardware modules in the system.

[0059] The cash register equipment and the payment capability expansion equipment are provided by different service providers (usually independent companies, which may not have a cooperative relationship with each other). The cash register equipment is a basic equipment that merchants usually use at the cash register. Common ones are desktop or handheld Android POS machines, etc., which can support one or more basic payment methods, such as bank card payment, membership card payment, QR code payment, etc. However, it does not support other relatively unconventional payment methods, such as NFC payment, face payment, palm payment, etc. Therefore, it is proposed to expand one or more other payment support capabilities through the solution of this application. Taking the NFC payment device as a payment capability expansion device as an example, it can provide NFC payment support capabilities. Users can sense by placing mobile terminals such as smartphones and smart watches that support NFC functions close to the payment capability expansion device, and then perform payment-related services based on near-field communication. Other face payment devices, palm payment devices, etc. can also be expanded in a similar way.

[0060] Figure 1 The process in includes the following steps:

[0061] S102: On the cash register device based on the Android operating system, an external software module provided by the service provider of the payment capability extension device is used to monitor accessibility service events issued by the Android operating system, and based on the accessibility service events, it is determined whether the user (e.g., cashier, consumer, etc.) has triggered a target business in the business page of the own software module of the cash register device.

[0062] In one or more embodiments of the present specification, the two concepts of self-owned software module and external software module are used for the convenience of distinction.

[0063] Proprietary software modules refer to the basic cash register software installed on the cash register device, which is usually a SaaS cash register application provided by a SaaS application service provider. Some cash register devices have their own cash register software, which is usually a hardware and software integrated solution provided by the same service provider; of course, merchants can also choose cash register software provided by another service provider for the current cash register device as needed.

[0064] The external software module is provided by the service provider of the payment capability expansion device (for example, the payment service provider mentioned above). The payment capability expansion device is pre-installed with the corresponding software, which is also provided by the service provider. Since they are under the R&D system of the same service provider, the connection between the software and the external software module will be easier to achieve at low cost. The problem in the background technology is essentially the connection between the software and the proprietary software module of the cash register device, which is not easy to achieve due to technical differences, costs and other reasons. This application mainly uses external software modules to replace the proprietary software modules to achieve the connection with the payment capability expansion device and its software, and the proprietary software module itself does not need to actively cooperate with the external software module. The external software module creates the desired data for the proprietary software module by itself, and basically does not affect the work of the proprietary software module.

[0065] Merchants can obtain external software modules from the service provider of the payment capability expansion device in advance and deploy (for example, install the corresponding software) on the cash register device. The external software module is used to determine whether the user has triggered the target business in the business page of the own software module. The target business can be one or more businesses that the payment capability expansion device is capable of at least partially executing, such as payment, member login, discount collection and other businesses. It should be noted that in order to avoid developing and modifying the own software module of the cash register device, the external software module does not directly access the interface with the own software module to obtain the user's behavior in the business page of the own software module, but infers the user's behavior based on accessibility service event monitoring and pre-made page area marking.

[0066] For the Android operating system, it can provide accessibility services to help developers provide convenience for some special users (for example, visually impaired users, hearing-impaired users), which can include AccessibilityService services. The AccessibilityService service can run in the background and can receive some events issued by the operating system, called AccessibilityEvent events, which can be used as the above-mentioned accessibility service events. Accessibility service events can represent at least one of the following state changes of the user interface on the cash register device: focus change, input content change, button click, etc. The AccessibilityService service can request to obtain the current active window and find the content therein. Various changes in the interface may generate a corresponding AccessibilityEvent event, which is notified to the AccessibilityService by the system. Based on this service provided by the Android operating system, this application actively monitors AccessibilityEvent events through external software modules, and is sensitive to some of the AccessibilityEvent events that are expected to be paid attention to, so as to immediately infer whether there is an opportunity for the payment capability expansion device to show its strengths.

[0067] Of course, by analyzing interface screenshots and detecting interaction coordinates (for example, by monitoring global click events and keyboard event lights), it is also possible to assist in determining whether the target business has been triggered. However, this requires relatively high device performance, may occupy higher CPU and memory resources, has relatively lower efficiency, and the information obtained may not be detailed enough. Therefore, it can be considered for use under non-Android operating systems.

[0068] On the other hand, judging based on accessibility service events can efficiently obtain more detailed dynamic information about the interaction between the user and the interface. Three AccessibilityEvent events are given as examples: for the "TYPE_VIEW_CLICKED" event, it can indicate that the user clicked on a specific view, such as a button, check box, etc.; for the "TYPE_VIEW_TEXT_CHANGED" event, it can indicate that the text in a specific view (such as a text box, etc.) has changed; for the "TYPE_NOTIFICATION_STATE_CHANGED" event, it can indicate that the notification status in the notification bar has changed.

[0069] External software modules can apply to the Android operating system on the cash register device in advance for corresponding permissions, and can use accessibility services normally after obtaining authorization.

[0070] In order to more reliably clarify the detailed business significance corresponding to the monitored accessibility service event and improve the accuracy of judgment, a pre-built decision model can also be combined to assist in the judgment. In one or more embodiments of this specification, it can be determined whether the user has triggered the target business in the business page based on the accessibility service event and the decision model, wherein the decision model is obtained by the service provider of the payment capability extension device based on the page focus elements pre-marked by the proprietary software module for the cash register device.

[0071] For ease of understanding, one or more embodiments of this specification provide a flowchart of a labeling model preprocessing solution, see Figure 2 .

[0072] Figure 2 The process in includes the following steps:

[0073] S202: Before determining whether the user has triggered the target business in the business page of the own software module of the cash register device based on the accessibility service event and the decision model, mark page attention elements for one or more SaaS cash register applications to obtain marking data, wherein the page attention elements include the page name, button and related text area of ​​interest.

[0074] Since the payment service provider needs to serve multiple merchants, there will be multiple cash register devices in the system, and not all merchants will choose the same cash register software (the above-mentioned proprietary software module). Different cash register software may have different page layouts, which will affect the accuracy of subsequent judgments. Therefore, in preprocessing, different cash register software can be processed separately. For example, taking the cash register software as an example, in step S202, assuming that the cash register software is a SaaS cash register application, if there are multiple SaaS cash register applications, it is necessary to mark the page attention elements for each SaaS cash register application.

[0075] Page focus elements are elements related to the target business, and the information provided may be helpful for subsequent judgments, such as the corresponding full-view business page name, window name, tab name, trigger button (such as payment button, member login button, etc., and the text on the button), text area (such as the display area for the amount to be paid, the display area for member nicknames), cashier application logo, etc.

[0076] By marking, the business significance of these page focus elements can be determined, so that it is easier to determine whether the user has interacted with the page focus elements (such as the payment button) or whether a page focus element (such as the text area for displaying the amount to be paid) has changed due to other user actions based on the page focus elements involved in the corresponding accessibility service events.

[0077] Of course, in addition to the more reliable and accurate method of decision-making models, other methods can also be used. For example, based on the callback data corresponding to the accessibility service event, a simpler regular expression (which can be designed in advance according to the relationship between page elements on the business page to filter different page elements) is matched to determine whether the target business is triggered.

[0078] S204: Convert the markup data into a decision model that reflects the corresponding relationship between the page focus element and the business or accessibility service event.

[0079] The decision model can be in various forms. For example, it can be a simple model in the form of a relatively simple data table, or it can be a more complex model such as a decision tree, decision forest, or even a machine learning model, and so on.

[0080] In the case of multiple SaaS cash register applications, multiple decision models can be obtained based on their respective targeted labeled data. Among these decision models, the decision model corresponding to each SaaS cash register application is selected, which helps to make subsequent judgments more accurately.

[0081] S206: Send the decision model to the cashier device where the corresponding SaaS cashier application is located.

[0082] The decision model can be sent to an external software module deployed on the cash register device to determine whether the user has triggered the target business on the business page; or the decision model can be called remotely. Figure 2 After the preprocessing process in is completed, you can execute Figure 1 The process in .

[0083] Continue to Figure 1 The next steps are described in .

[0084] S104: If yes, interact with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service provider.

[0085] If the target business itself has enough information to support correct execution, the corresponding capability requirement data can be directly generated locally or on the payment capability expansion device based on the target business. In addition, if necessary, auxiliary data can be obtained by monitoring the voice broadcast of the cash register device (if any), actively asking through synthetic voice, etc., and then generating capability requirement data based on the target business and auxiliary data.

[0086] In one or more embodiments of the present specification, the capability requirement data may be data that is as light as possible (e.g., a simple string, a simple message, or a text with a small amount of data, etc.). In this case, the capability requirement data is generated by an external software module and then transmitted from the cash register device to the payment capability expansion device. In this way, the transmission capability requirement is relatively low (e.g., it can be transmitted based on a small serial port instruction), which also helps to improve efficiency. On the contrary, if the transmission capability is strong, the screenshot image and service data can also be used as capability requirement data (with a relatively larger amount of data) and transmitted to the payment capability expansion device, which is further analyzed and used by the payment capability expansion device.

[0087] S106: On the payment capability extension device, execute the corresponding target business according to the capability requirement data, and return the execution result data to the cash register device.

[0088] In one or more embodiments of this specification, taking the NFC payment device as a payment capability expansion device as an example, after the NFC payment device obtains the capability requirement data, it can wait for the user (e.g., consumer) to bring the mobile phone close to the NFC payment device for induction recognition. If the user does not do so, it indicates that the user may not want to execute the target business through the NFC payment device. In this case, the NFC payment device can return to the standby state after the waiting timeout to wait for the next opportunity. If the user cooperates with the operation, the NFC payment device can execute the target business accordingly. Of course, the consumer can also perform NFC induction recognition in advance, and then the cashier can operate on the cash register device, and then complete the execution of the target business with the cooperation of the cash register device and the NFC payment device.

[0089] Similarly, for face-scanning payment devices, palm-scanning payment devices, etc., they wait for the user to perform corresponding cooperative operations such as face-scanning or palm-scanning, and then execute the target business.

[0090] It should be noted that the payment capability extension device may only complete a part of the work included in the target business. For example, it may identify the user's payment code value as the execution result data and return it to the cash register device, and the cash register device will further complete the target business based on the execution result data. On the contrary, if the payment capability extension device basically completes the target business, the execution result data may only be a final result for feedback to the consumer.

[0091] pass Figure 1The method makes it unnecessary for the payment service provider of the payment capability extension device (such as merchants, cash register service providers, etc.) to develop and transform the cash register device and its own software modules (such as SaaS cash register applications), integrate software development kit processing interfaces, etc. Instead, it is only necessary to simply deploy the external software module provided by the payment service provider on the cash register device, connect the cash register device with the payment capability extension device through methods such as serial ports, and conveniently access the corresponding extended payment support capabilities. The own software module does not need to make cumbersome interface calls for the payment capability extension device (such as NFC payment devices), and does not need to cooperate with the external software module for additional development. Instead, the external software module actively monitors the Android The operating system sends out accessibility service events, and infers whether there is an opportunity for the payment capability expansion device to play a role based on the accessibility service events, without the need to adopt more cumbersome means such as coordinate position detection and screenshot analysis. If it is inferred that there is an opportunity, it will generate capability demand data (for example, interface call data) accordingly, and replace its own software module to interact with the payment capability expansion device, so as to help the cash register device and its own software module to realize the use of the extended payment support capability. It can be seen that this solution is mainly transformed and deployed by the payment service provider itself. Customers can easily expand access to payment capability expansion devices without development and modification. It is more user-friendly and also helps the payment service provider to expand NFC payment business and other extended payment businesses more widely.

[0092] based on Figure 1 This specification also provides some specific implementation plans and extension plans of the method, which will be described below.

[0093] Generally speaking, the performance of cash register equipment is stronger than that of payment capability expansion equipment, especially desktop cash register equipment. Therefore, it is considered to utilize the computing power of cash register equipment and generate capability requirement data by external software module. Based on this, one or more embodiments of this specification provide a flow chart of capability requirement data processing solution, see Figure 3 .

[0094] Figure 3 The process in includes the following steps:

[0095] S302: Determine, through the external software module, an interface to be called that is adapted to the service provider of the payment capability extension device and input parameters adapted to the interface to be called according to the target business and the barrier-free service provided by the Android operating system.

[0096] Continuing with the example of payment and NFC payment devices, the interface to be called is, for example, an interface for requesting the NFC payment device to read the payment code value from the consumer's mobile phone based on near-field communication sensing. The input parameters include, for example, the amount to be paid. The payment code value to be read is the code value corresponding to the amount to be paid, and based on the payment code value, the authority is granted to deduct the amount to be paid from the current consumer's account.

[0097] In one or more embodiments of the present specification, an external software module can globally read layout information through the above-mentioned accessible attachment service to obtain more detailed information such as the above-mentioned amount to be paid, so as to more accurately and reliably determine the interface to be called and / or its input parameters for the target business.

[0098] S304: Generate interface calling data as capability requirement data according to the interface to be called and the input parameters.

[0099] In one or more embodiments of the present specification, the interface call data may be an interface call request that complies with a preset interface standard for the payment capability expansion device, thereby facilitating direct use by the payment capability expansion device; alternatively, the interface call data or other forms of capability requirement data may be lighter description data, and may even be simply described in natural language, and then further converted and used by the payment capability expansion device.

[0100] S306: Sending the capability requirement data to the payment capability expansion device via the cash register device.

[0101] If the interface call data is an interface call request, the sending process is equivalent to the external software module calling the interface provided by the software on the payment capability expansion device. Otherwise, the sending process is just a relatively simple data transmission process. For this type of situation, for example, a simple message (such as a small number of words, a short string, individual fields, etc.) can be generated by the external software module, and the simple message can be sent from the cash register device to the payment capability expansion device through serial communication, so that the payment capability expansion device converts the simple message into the interface call data adapted to its service party as the capability demand data; in this way, the requirements for external software modules and transmission capabilities can be reduced, and the impact on the cash register device will be further reduced, which will help improve security.

[0102] According to the above description, in order to facilitate implementation and be more intuitive, one or more embodiments of this specification also provide a flowchart of a specific implementation scheme of the payment service processing method in the Android scenario, see Figure 4 .exist Figure 4In the scenario, the above-mentioned cash register device is specifically an Android POS machine (for example, using Android 4.0 or above system) used by the merchant's offline store, and the proprietary software module is specifically a SaaS cash register application installed on the Android POS machine.

[0103] Figure 4 The solution consists of two phases: configuration preparation phase and actual operation phase.

[0104] The configuration preparation phase mainly includes the following steps:

[0105] Install the research-free application APK (belonging to the above-mentioned external software module) provided by the payment service provider on the Android POS machine, and authorize the accessibility service permission.

[0106] Run the automated collection and marking software provided by the payment service provider (which may also belong to the external software module mentioned above), and mark the key page component names, buttons, text areas, etc. of the payment, membership and other traffic routes in the SaaS cash register application according to the instructions.

[0107] The marked data is converted into specific decision models and script data such as business, coordinates, or events, and uploaded to the cloud, and stored in association with the corresponding SaaS cash register application package name, version and other identifiers for accurate distribution.

[0108] The actual operation phase mainly includes the following steps:

[0109] The marked decision model, script data, etc. are distributed to the Android POS machine where the corresponding SaaS cash register application is located. The background application starts and runs automatically when the machine is turned on, and the monitoring and judgment processing software provided by the payment service provider is deployed on the Android POS machine (belonging to the above-mentioned external software module, which may include the previously deployed free research application APK). It starts and runs automatically when the machine is turned on, which can pre-process the security issues of the system registry and device security software and obtain the corresponding self-starting permissions.

[0110] Monitor accessibility service events, and combine the callback page name, button name, text and other information with the decision model, and pass them into the dynamic script to judge actions such as payment and member login, that is, to determine whether the target business is triggered.

[0111] Based on actions such as payment and member login, the accessible service can globally read the layout information to obtain the amount or member information and convert it into specific interface calls and input parameter data.

[0112] The Android POS machine uses the processing software deployed by the payment service provider to call the interface and input parameters to pass data to payment capability expansion devices such as NFC payment, face payment, and palm payment through small instructions, and then the device side executes payment, member login and other services. For the transmission method here, for example, the two devices can be connected through the KD4 serial port, supporting two-way communication of small instructions between the two devices.

[0113] After the payment capability expansion device executes the target business such as payment and membership, it simulates the human interface device through the Human Interface Device (HID) protocol, and fills the obtained data corresponding to the target business (for example, the business code value) back into the corresponding input box of the SaaS cash register application of the Android POS machine, thereby realizing the business flow connection between the SaaS cash register application and the software on the payment capability expansion device. Among them, the human interface device protocol supports the one-way transmission mode from the payment capability expansion device to the Android POS machine, which is convenient for efficient direct backfilling of data without going through the above-mentioned external software module.

[0114] In the previous solution, users are directly allowed to trigger the target business through the original buttons and other areas of the own software module. However, for some cash register applications, the prompt information for the area may be more rigorous, and they do not originally support payment methods such as NFC, face recognition, or palm recognition. Therefore, there may be ambiguity or conflict with these extended business areas, which may cause user misunderstanding. In order to reduce this risk, this application considers adding additional page layout patches to indirectly help users correctly trigger the target business. For example, the page layout patch can more clearly indicate the relationship between the extended capabilities and the target business. Combined with Figure 5 To explain, Figure 5 A flow chart of a page layout patch processing solution is provided for one or more embodiments of the present specification.

[0115] Figure 5 The process in includes the following steps:

[0116] S502: Generate a visualized page layout patch according to the target business.

[0117] The page layout patch can be made into a control form such as a button or a slider, and is a part of an external software module. It can provide more correct and reliable prompts for the page layout patch to facilitate user interaction.

[0118] In one or more embodiments of the present specification, a business page simulation style learned based on the business page can be obtained; based on the target business and the business page simulation style, a page layout patch with a visual style consistent with the business page is generated to facilitate subsequent supplementary layout, and after the layout, the global appearance is coordinated, so that users can more easily understand the page layout patch as an original part of the business page.

[0119] S504: Generate an additional local layer for the business page, determine the proprietary trigger control of the proprietary software module that matches the business page with the target business, and display the page layout patch in the area of ​​the local layer corresponding to the proprietary trigger control.

[0120] Furthermore, the page layout patch can be displayed in a local layer. In order to prevent the impact on possible interactions in other areas of the business page, the size of the page layout patch can be made sufficient to avoid unnecessary expansion of the range. The corresponding local layer can also be limited to a sufficient range as much as possible.

[0121] In addition to the method of adding additional layers, if the cash register equipment and the proprietary software module have given authorization, the page layout patch can also be embedded directly into the business page through other methods such as front-end code injection, so that the integration effect is better.

[0122] In one or more embodiments of this specification, since this application is capable of and focuses on monitoring accessibility service events, it is expected that the corresponding accessibility service events can also be triggered through the page layout patch. Of course, the page layout patch itself can be made into a triggerable control, but this method is not conducive to security and cost control. Therefore, this application considers mainly using the page layout patch to guide users to trigger existing controls in the own software module (that is, the own trigger control mentioned in step S504, such as the payment button, login button, etc.). In order to achieve this purpose, the display position of the page layout patch can be deployed as in step S504.

[0123] S506: Determine whether the user triggers the own trigger control by triggering the page layout patch on the business page.

[0124] In one or more embodiments of the present specification, it can be determined whether the user has triggered a page layout patch on a business page. Since the page layout patch can provide more accurate prompts, the user can more accurately trigger the page layout patch when there is a need to use extended payment capabilities. This action actually shows the user's intention to trigger the target business. Therefore, the external software module can then determine that the user has triggered the target business, or actually trigger the target business on behalf of the user.

[0125] Based on the previous page layout patch deployment ideas, if the user triggers the page layout patch, there is a high probability that the corresponding self-triggered control will also be triggered at the same time. In this case, the external software module can determine that the user has triggered the target service based on the corresponding accessibility service event, without having to trigger the target service on behalf of the user again.

[0126] In one or more embodiments of the present specification, the page layout patch can be displayed in a first sub-area in an area corresponding to an own trigger control in a local layer, and a second sub-area in an area not covered by the local layer but not covering the own trigger control. The first sub-area and the second sub-area are different areas. There can be one or more first sub-areas (in the case of multiple areas, for example, they correspond to different payment capability expansion devices respectively), and there can be one or more second sub-areas (in the case of multiple areas, for example, they correspond to different interaction channels other than the payment capability expansion device respectively).

[0127] In this case, further, when judging whether the user is on the business page and triggers the page layout patch, the following can be performed: judging whether the user is on the business page and triggers the first sub-area or the second sub-area (for example, it can be judged by analyzing the monitored accessibility service events, or by other means of obtaining interaction coordinates); if the first sub-area is triggered, the corresponding target business is executed by interacting with the payment capability extension device; if the second sub-area is triggered, the corresponding target business is executed through another interaction channel corresponding to the own trigger control. Another interaction channel can be a payment method originally supported by the cash register device, such as scan code payment, bank card payment, etc.

[0128] No matter whether the user triggers the first sub-area or the second sub-area, the proprietary trigger control may be indirectly triggered. Here, by distinguishing the trigger areas, even if the same proprietary trigger control is triggered, differentiated interaction channels may be adopted later. In this way, the user can very conveniently and clearly choose to use the extended payment method or the original payment method. Moreover, it has little impact on the user's operating habits, can make the business interface more neat and beautiful, and helps to reduce the security risks of local layers.

[0129] S508: If yes, it is determined that the user has triggered the target service.

[0130] In this case, the judgment result obtained in step S102 is yes. It can be seen that in this process, there is no need for the cooperation of the own software module for development and transformation, and the usability of the solution for users is further improved. Not only that, the solution can be more easily reused on other businesses or payment capability expansion devices by lightweight adjustment of the page layout patch.

[0131] Figure 1 The cash register equipment and payment capability expansion equipment are described from the perspective of the whole. For the payment service provider, the transformation is mainly reflected in the above-mentioned external software modules. Therefore, based on the same idea, the description is re-made from the perspective of the external software modules. Figure 6 , Figure 6 A flowchart of another payment service processing method in an Android scenario provided for one or more embodiments of this specification.

[0132] This another payment service processing method in an Android scenario is applied to an external software module provided by a service provider of a payment capability expansion device, and the external software module is pre-deployed on a cash register device. Figure 6 The process in includes the following steps:

[0133] S602: On the cash register device based on the Android operating system, listen to the accessibility service events issued by the Android operating system, and determine whether the user has triggered a target service in the service page of the own software module of the cash register device according to the accessibility service events.

[0134] S604: If yes, interact with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider and executes corresponding target services according to the capability requirement data.

[0135] You can refer to the previous description to understand Figure 6 The steps in are not repeated here.

[0136] Since the external software modules are provided by the service provider of the payment capability expansion device, there is no need for merchants, cash register equipment and cash register software to carry out development and modification. This is more friendly to them and helps increase merchants' enthusiasm for expanding the use of payment capability expansion devices.

[0137] Based on the same idea, one or more embodiments of this specification also provide devices and apparatuses corresponding to the above methods, such as Figure 7~Figure 11 The apparatus and device can accordingly execute the above method and related optional solutions.

[0138] Figure 7 A schematic diagram of a payment service processing device in an Android scenario provided in one or more embodiments of this specification is applied to a system including a cash register device and a payment capability expansion device, and the device includes:

[0139] The service trigger detection module 702 monitors the accessibility service events issued by the Android operating system on the cash register device based on the Android operating system through the external software module provided by the service provider of the payment capability extension device, and determines whether the user triggers the target service in the service page of the own software module of the cash register device according to the accessibility service event;

[0140] Adaptation capability requirement module 704, if yes, interacts with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0141] The target business interactive execution module 706 executes the corresponding target business according to the capability requirement data on the payment capability extension device, and returns the execution result data to the cash register device.

[0142] Optionally, the accessibility service event includes: an AccessibilityEvent event issued by the AccessibilityService service.

[0143] Optionally, the accessibility service event represents at least one of the following state changes of the user interface on the cash register device: focus change, input content change, button click.

[0144] Optionally, the payment capability expansion device includes at least one of the following: an NFC payment device, a face-swiping payment device, and a palm-swiping payment device.

[0145] Optionally, the business trigger detection module 702 determines whether the user has triggered the target business in the business page of the proprietary software module of the cash register device based on the accessibility service event and the decision model, wherein the decision model is obtained by the service provider of the payment capability extension device based on the page attention elements pre-marked for the proprietary software module of the cash register device.

[0146] Optionally, the proprietary software module of the cash register device includes a SaaS cash register application, and the SaaS cash register application and the payment capability extension device are provided by different service providers.

[0147] Optionally, the system includes multiple cash register devices, and at least two cash register devices among the multiple cash register devices have different SaaS cash register applications, which are provided by different service providers.

[0148] Optionally, it also includes:

[0149] The external software preprocessing module 708, before determining whether the user has triggered a target business in the business page of the self-owned software module of the cash register device according to the accessibility service event and the decision model, marks page attention elements for one or more SaaS cash register applications to obtain marking data, wherein the page attention elements include the page name, button and related text area of ​​the attention;

[0150] Converting the marked data into a decision model reflecting the corresponding relationship between the page focus element and the business or accessibility service event;

[0151] The decision model is sent to the cash register device where the corresponding SaaS cash register application is located.

[0152] Optionally, the adaptation capability requirement module 704 generates capability requirement data adapted to the service provider of the payment capability extension device according to the target business;

[0153] The capability requirement data is sent to the payment capability expansion device through the cash register device.

[0154] Optionally, the adaptability requirement module 704 determines, according to the target business and the barrier-free service provided by the Android operating system, an interface to be called that is adapted to the service provider of the payment capability extension device, and input parameters adapted to the interface to be called;

[0155] According to the interface to be called and the input parameters, interface calling data is generated as capability requirement data.

[0156] Optionally, the adaptation capability requirement module 704 generates a simple message through the external software module according to the target business, and sends the simple message from the cash register device to the payment capability expansion device through serial port communication, so that the payment capability expansion device converts the simple message into interface call data adapted to its service provider as capability requirement data.

[0157] Optionally, the execution result data includes a service code value of the user corresponding to the target service;

[0158] The target business interaction execution module 706 fills the business code value of the user corresponding to the target business into the corresponding input box of the own software module of the cash register device through the human-machine interface device protocol.

[0159] Optionally, the business trigger detection module 702 generates a visualized page layout patch according to the target business;

[0160] For the business page, generate an additional local layer, and display the page layout patch in the local layer;

[0161] Determine whether the user has triggered the page layout patch on the business page;

[0162] If so, the service control of the own software module corresponding to the target service is automatically triggered, and it is determined that the user has triggered the target service.

[0163] Optionally, the business trigger detection module 702 determines the business page matches the target business, and the own trigger control of the own software module;

[0164] Displaying the page layout patch in the area of ​​the local layer corresponding to the own trigger control;

[0165] It is determined whether the user is on the business page and triggers the own trigger control by triggering the page layout patch.

[0166] Optionally, the business trigger detection module 702 displays the page layout patch in a first sub-region in the region of the local layer corresponding to the own trigger control, and a second sub-region in the region of the own trigger control not covered by the local layer, and the first sub-region and the second sub-region are different regions;

[0167] Determining whether the user triggers the first sub-area or the second sub-area on the business page;

[0168] If the first sub-area is triggered, executing a corresponding target service by interacting with the payment capability extension device;

[0169] If the second sub-area is triggered, the corresponding target business is executed through another interactive channel corresponding to the own trigger control.

[0170] Optionally, the business trigger detection module 702 obtains a business page simulation style learned from the business page;

[0171] A page layout patch whose visual style is consistent with the business page is generated according to the target business and the business page simulation style.

[0172] Optionally, the target service can be executed on the cash register device in a manner other than NFC;

[0173] The target service interactive execution module 706 executes the target service on the payment capability extension device according to the capability requirement data and based on the corresponding extended payment method.

[0174] Optionally, the target business includes: payment or member login.

[0175] Figure 8 A schematic diagram of the structure of another payment service processing device in an Android scenario provided in one or more embodiments of this specification, which is applied to an external software module provided by a service provider of a payment capability expansion device, and the external software module is pre-deployed on a cash register device, and the device includes:

[0176] A monitoring and judging module 802 monitors, on the cash register device based on the Android operating system, an accessibility service event issued by the Android operating system, and judges, based on the accessibility service event, whether the user has triggered a target service in a service page of a proprietary software module of the cash register device;

[0177] Interaction module 804, if yes, interacts with the payment capability extension device, so that the payment capability extension device obtains capability requirement data adapted to its service provider, and executes the corresponding target business according to the capability requirement data.

[0178] Fig. 9 A schematic diagram of the structure of a cash register device provided in one or more embodiments of the present specification, wherein the cash register device includes a proprietary software module and an external software module provided by a service provider of a payment capability expansion device;

[0179] The self-owned software module provides a business page to the user so that the user can interact in the business page;

[0180] The external software module monitors the accessibility service event issued by the Android operating system on the cash register device based on the Android operating system, and determines whether the user triggers the target service in the service page of the own software module of the cash register device according to the accessibility service event;

[0181] If yes, interact with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0182] The self-owned software module receives the execution result data returned by the payment capability expansion device and obtained by executing the corresponding target business according to the capability requirement data.

[0183] Fig.10A schematic diagram of the structure of a payment service processing device in an Android scenario provided for one or more embodiments of this specification is applied to a system including a cash register device and a payment capability expansion device. The payment service processing device in the Android scenario includes:

[0184] at least one processor; and,

[0185] a memory communicatively connected to the at least one processor; wherein,

[0186] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute:

[0187] On the cash register device based on the Android operating system, an external software module provided by the service provider of the payment capability extension device is used to monitor an accessibility service event issued by the Android operating system, and based on the accessibility service event, it is determined whether the user has triggered a target service in a service page of the own software module of the cash register device;

[0188] If yes, interacting with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0189] On the payment capability expansion device, the corresponding target business is executed according to the capability requirement data, and the execution result data is returned to the cash register device.

[0190] Fig.11 A schematic diagram of the structure of another payment service processing device in an Android scenario provided in one or more embodiments of this specification, which is applied to an external software module provided by a service provider of a payment capability expansion device, and the external software module is pre-deployed on a cash register device. The payment service processing device in the Android scenario includes:

[0191] at least one processor; and,

[0192] a memory communicatively connected to the at least one processor; wherein,

[0193] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute:

[0194] On the cash register device based on the Android operating system, monitoring an accessibility service event issued by the Android operating system, and judging whether the user has triggered a target service in a service page of a proprietary software module of the cash register device according to the accessibility service event;

[0195] If so, the payment capability extension device interacts with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider and executes the corresponding target business according to the capability requirement data.

[0196] Based on the same idea, one or more embodiments of this specification further provide a non-volatile computer storage medium, which is applied to a system including a cash register device and a payment capability expansion device, wherein the medium stores computer executable instructions, and the computer executable instructions are configured as follows:

[0197] On the cash register device based on the Android operating system, an external software module provided by the service provider of the payment capability extension device is used to monitor an accessibility service event issued by the Android operating system, and based on the accessibility service event, it is determined whether the user has triggered a target service in a service page of the own software module of the cash register device;

[0198] If yes, interacting with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service provider;

[0199] On the payment capability expansion device, the corresponding target business is executed according to the capability requirement data, and the execution result data is returned to the cash register device.

[0200] One or more embodiments of the present specification further provide another non-volatile computer storage medium, which is applied to an external software module provided by a service provider of a payment capability expansion device, wherein the external software module is pre-deployed on a cash register device, and the medium stores computer executable instructions, wherein the computer executable instructions are configured as follows:

[0201] On the cash register device based on the Android operating system, monitoring an accessibility service event issued by the Android operating system, and judging whether the user has triggered a target service in a service page of a proprietary software module of the cash register device according to the accessibility service event;

[0202] If so, the payment capability extension device interacts with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider and executes the corresponding target business according to the capability requirement data.

[0203] In the 1990s, it was very clear whether the improvement of a technology was hardware improvement (for example, improvement of the circuit structure of diodes, transistors, switches, etc.) or software improvement (improvement of the method flow). However, with the development of technology, many improvements of the method flow today can be regarded as direct improvements of the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented with hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask chip manufacturers to design and make dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, 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, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0204] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.

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

[0206] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0207] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of this specification may 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 codes.

[0208] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0209] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0210] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0212] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0213] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0214] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, an element defined by the sentence "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity or device including the element.

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

[0216] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0217] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0218] The above description is only one or more embodiments of this specification and is not intended to limit this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of this specification shall be included in the scope of the claims of this specification.

Claims

1. A payment service processing method in an Android scenario, applied to a system including a cash register device and a payment capability expansion device, the method comprising: On the cash register device based on the Android operating system, an external software module provided by the service provider of the payment capability extension device is used to monitor the accessibility service event issued by the Android operating system, and according to the accessibility service event, it is determined whether the user has triggered a target service in the service page of the own software module of the cash register device, wherein the accessibility service event includes: an AccessibilityEvent event issued by the AccessibilityService service; If so, interacting with the payment capability extension device through the external software module so that the payment capability extension device obtains capability requirement data adapted to its service provider, wherein the capability requirement data is generated according to the target service; the capability requirement data is generated locally by the external software module and then transmitted to the payment capability extension device, or is generated on the payment capability extension device; On the payment capability expansion device, the corresponding target business is executed according to the capability requirement data, and the execution result data is returned to the cash register device.

2. The method as claimed in claim 1, wherein the accessibility service event represents at least one of the following state changes of the user interface on the cash register device: focus change, input content change, button click.

3. According to the method of claim 1, the payment capability expansion device includes at least one of the following: an NFC payment device, a face-swiping payment device, and a palm-swiping payment device.

4. The method according to claim 1, wherein judging whether the user has triggered a target service in a service page of a proprietary software module of the cash register device according to the accessibility service event specifically comprises: Based on the accessibility service event and the decision model, it is determined whether the user has triggered the target business in the business page of the proprietary software module of the cash register device, wherein the decision model is obtained by the service provider of the payment capability extension device based on the page attention elements pre-marked for the proprietary software module of the cash register device.

5. The method according to claim 4, wherein the proprietary software module of the cash register device comprises a SaaS cash register application, and the SaaS cash register application and the payment capability extension device are provided by different service providers.

6. The method as claimed in claim 5, wherein the system comprises a plurality of cash register devices, and at least two of the plurality of cash register devices have different SaaS cash register applications, which are provided by different service providers.

7. The method of claim 5, wherein before determining whether the user has triggered a target service in a service page of a proprietary software module of the cash register device based on the accessibility service event and the decision model, the method further comprises: Marking page attention elements for one or more SaaS cash register applications to obtain marking data, wherein the page attention elements include the page name, button and related text area of ​​the attention; Converting the marked data into a decision model reflecting the corresponding relationship between the page focus element and the business or accessibility service event; The decision model is sent to the cash register device where the corresponding SaaS cash register application is located.

8. The method according to claim 1, wherein the interacting with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider comprises: Generating capability requirement data adapted to the service provider of the payment capability extension device according to the target business; The capability requirement data is sent to the payment capability expansion device through the cash register device.

9. The method according to claim 8, wherein generating capability requirement data adapted to the service provider of the payment capability extension device according to the target business specifically comprises: According to the target business and the barrier-free service provided by the Android operating system, determine an interface to be called that is adapted to the service provider of the payment capability extension device, and input parameters adapted to the interface to be called; According to the interface to be called and the input parameters, interface calling data is generated as capability requirement data.

10. The method according to claim 1, wherein the interaction with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider comprises: Through the external software module, a simple message is generated according to the target business, and the simple message is sent from the cash register device to the payment capability expansion device through serial port communication, so that the payment capability expansion device converts the simple message into interface call data adapted to its service provider as capability requirement data.

11. The method according to claim 1, wherein determining whether the user has triggered the target service in the service page specifically comprises: Generate visual page layout patches based on target business; For the business page, generate an additional local layer, and display the page layout patch in the local layer; Determine whether the user has triggered the page layout patch on the business page; If so, the service control of the own software module corresponding to the target service is automatically triggered, and it is determined that the user has triggered the target service.

12. The method according to claim 11, wherein displaying the page layout patch in the local layer comprises: Determine the business page matches the target business, and the proprietary trigger control of the proprietary software module; Displaying the page layout patch in the area of ​​the local layer corresponding to the own trigger control; The determining whether the user has triggered the page layout patch on the business page specifically includes: It is determined whether the user is on the business page and triggers the own trigger control by triggering the page layout patch.

13. The method according to claim 12, wherein displaying the page layout patch in the area of ​​the local layer corresponding to the own trigger control specifically comprises: Displaying the page layout patch in a first sub-region of the region corresponding to the own trigger control in the local layer, wherein the local layer does not cover a second sub-region of the region of the own trigger control, wherein the first sub-region and the second sub-region are different regions; The determining whether the user has triggered the page layout patch on the business page specifically includes: Determine whether the user triggers the first sub-area or the second sub-area on the business page; If the first sub-area is triggered, executing a corresponding target service by interacting with the payment capability extension device; If the second sub-area is triggered, the corresponding target business is executed through another interactive channel corresponding to the own trigger control.

14. The method according to claim 11, wherein generating a visualized page layout patch according to the target business specifically comprises: Obtaining a business page simulation style learned from the business page; A page layout patch whose visual style is consistent with the business page is generated according to the target business and the business page simulation style.

15. A payment service processing method in an Android scenario, applied to an external software module provided by a service provider of a payment capability expansion device, the external software module being pre-deployed on a cash register device, the method comprising: On the cash register device based on the Android operating system, an accessibility service event issued by the Android operating system is monitored, and according to the accessibility service event, it is determined whether the user has triggered a target service in a service page of a software module of the cash register device, wherein the accessibility service event includes: an AccessibilityEvent event issued by the AccessibilityService service; If so, interact with the payment capability expansion device so that the payment capability expansion device obtains capability requirement data adapted to its service provider and executes corresponding target business according to the capability requirement data, wherein the capability requirement data is generated according to the target business; the capability requirement data is generated locally by the external software module and then transmitted to the payment capability expansion device, or is generated on the payment capability expansion device.

16. A payment service processing device in an Android scenario, applied to a system including a cash register device and a payment capability expansion device, the device comprising: A service trigger detection module, on the cash register device based on the Android operating system, monitors the accessibility service events issued by the Android operating system through an external software module provided by the service provider of the payment capability extension device, and determines whether the user has triggered the target service in the service page of the own software module of the cash register device according to the accessibility service event, wherein the accessibility service event includes: an AccessibilityEvent event issued by the AccessibilityService service; Adapting capability requirement module, if yes, interacting with the payment capability extension device through the external software module, so that the payment capability extension device obtains capability requirement data adapted to its service party, the capability requirement data is generated according to the target business; the capability requirement data is generated locally by the external software module and then transmitted to the payment capability extension device, or is generated on the payment capability extension device; The target business interactive execution module executes the corresponding target business according to the capability requirement data on the payment capability extension device, and returns the execution result data to the cash register device. 17 . The apparatus of claim 16 , wherein the accessibility service event represents at least one of the following state changes of the user interface on the cash register device: focus change, input content change, button click.

18. The apparatus as claimed in claim 16, wherein the payment capability expansion device comprises at least one of the following: an NFC payment device, a face-swiping payment device, and a palm-swiping payment device.

19. The device of claim 16, wherein the service trigger detection module determines whether the user has triggered a target service in a service page of a proprietary software module of the cash register device according to the accessibility service event and the decision model, wherein: The decision model is obtained by the service provider of the payment capability extension device according to the page focus elements pre-marked by the proprietary software module of the cash register device.

20. The apparatus of claim 19, wherein the proprietary software module of the cash register device comprises a SaaS cash register application, and the SaaS cash register application and the payment capability extension device are provided by different service providers.

21. The apparatus of claim 20, further comprising: The external software preprocessing module marks page attention elements for one or more SaaS cash register applications to obtain marking data before determining whether the user has triggered a target business in a business page of the own software module of the cash register device according to the accessibility service event and the decision model, wherein the page attention elements include the page name, button and related text area of ​​interest; Converting the marked data into a decision model reflecting the corresponding relationship between the page focus element and the business or accessibility service event; The decision model is sent to the cash register device where the corresponding SaaS cash register application is located.

22. A cash register device, comprising a proprietary software module and an external software module provided by a service provider that extends the device through payment capabilities; The self-owned software module provides a business page to the user so that the user can interact in the business page; The external software module, on the cash register device based on the Android operating system, monitors the accessibility service event issued by the Android operating system, and determines whether the user has triggered a target service in the service page of the own software module of the cash register device according to the accessibility service event, wherein the accessibility service event includes: an AccessibilityEvent event issued based on the AccessibilityService service; If so, interact with the payment capability extension device so that the payment capability extension device obtains capability requirement data adapted to its service provider, wherein the capability requirement data is generated according to the target service; the capability requirement data is generated locally by the external software module and then transmitted to the payment capability extension device, or is generated on the payment capability extension device; The self-owned software module receives the execution result data returned by the payment capability expansion device and obtained by executing the corresponding target business according to the capability requirement data.

23. A payment service processing device in an Android scenario, applied to an external software module provided by a service provider of a payment capability expansion device, wherein the external software module is pre-deployed on a cash register device, and the payment service processing device in an Android scenario comprises: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute: On the cash register device based on the Android operating system, an accessibility service event issued by the Android operating system is monitored, and according to the accessibility service event, it is determined whether the user has triggered a target service in a service page of a software module of the cash register device, wherein the accessibility service event includes: an AccessibilityEvent event issued by the AccessibilityService service; If so, interact with the payment capability expansion device so that the payment capability expansion device obtains capability requirement data adapted to its service provider and executes corresponding target business according to the capability requirement data, wherein the capability requirement data is generated according to the target business; the capability requirement data is generated locally by the external software module and then transmitted to the payment capability expansion device, or is generated on the payment capability expansion device.

Images