Payment service processing method, apparatus and device in android scenario, and point of sale device

Abstract

Disclosed in the embodiments of the present disclosure is a payment service processing method in an Android scenario. The method is applied to a system comprising a point of sale device and a payment capability extension device, and comprises: on a point of sale device, by means of an external software module provided by a service provider of a payment capability extension device, testing position data of a user's interaction in a service page of a native software module of the point of sale device, and on the basis of the position data, determining whether a user has triggered a target service in the service page; if so, interacting with the payment capability extension device by means of the external software module, such that the payment capability extension device obtains capability requirement data adapted to the service provider thereof; and on the payment capability extension device, executing a corresponding target service on the basis of the capability requirement data, and returning execution result data to the point of sale device.

Description

Payment service processing method, device and equipment in Android scenario and cash register equipment TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of near field communication, and particularly relates to a payment service processing method, device and equipment in an Android scenario and a cash register equipment. BACKGROUND

[0002] Near Field Communication (NFC) is a short-range high-frequency radio technology operating at 13.56 MHz within a 20-centimeter distance. It is evolved from non-contact radio frequency identification (RFID) and interconnection technology, and provides a very safe and fast communication method for various electronic products.

[0003] With the popularization of smart phones supporting NFC function, NFC technology is also more applied in the payment field. For example, a merchant deploys an NFC payment device at a cash register, and a user can make a payment through inductive interaction with the NFC payment device through a smart phone supporting NFC function, which is convenient.

[0004] At present, the NFC payment device and the corresponding payment application are provided by a special payment service provider. The merchant has usually deployed a cash register device and a cash register software provided by other service providers at the cash register, and the operating system of the cash register software is mostly an Android system. In this case, if the merchant wants to normally use the NFC payment device provided by the payment service provider to obtain corresponding NFC payment support capability, the merchant needs to develop and access to make the cash register device and the cash register software and the NFC payment device and the payment application normally docked. Therefore, the merchant or the service provider of the cash register device and the cash register software (referred to as a customer from the perspective of the payment service provider) needs to integrate a software development kit (SDK) to develop codes to call and process corresponding interface logic. The customer involves development, testing, deployment and other processes, and the overall cycle is relatively long (usually several weeks or even months). Moreover, most of the cash register software technology stacks are old and have poor maintainability, and changing codes may trigger many online problems. Furthermore, in actual application, there are many cash register devices and cash register software, which involve different service providers. Therefore, with the popularization and spread of NFC payment devices, the total development and access cost of numerous customers will be higher.

[0005] Not only NFC payment devices, but also other payment devices such as face payment devices and palm payment devices, which are not very traditional, also have similar problems. These devices are collectively referred to as payment capability expansion devices.

[0006] Based on this, for the cash register device and its cash register software in the merchant Android scenario, a more friendly solution is needed, which can extend access to payment capability expansion devices such as NFC payment devices, so that the merchant can obtain capabilities such as NFC payment support capability. SUMMARY

[0007] One or more embodiments of the present disclosure provide a payment business processing method and device in an Android scenario, and a cash register device, to solve the technical problem that for the cash register device and its cash register software in the merchant Android scenario, a more friendly solution is needed, which can extend access to payment capability expansion devices such as NFC payment devices, so that the merchant can obtain capabilities such as NFC payment support capability.

[0008] To solve the above technical problem, one or more embodiments of the present disclosure are implemented as follows.

[0009] One or more embodiments of the present disclosure provide a payment business 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 an Android operating system, listening to an accessibility service event issued by the Android operating system through an external software module provided by a service side of the payment capability expansion device, judging whether a user has triggered a target business in a business page of a self-owned software module of the cash register device according to the accessibility service event; if yes, 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 the service side thereof; on the payment capability expansion device, executing a corresponding target business according to the capability requirement data, and returning execution result data to the cash register device.

[0010] One or more embodiments of the present disclosure provide a payment business processing method in an Android scenario, applied to an external software module provided by a service side 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 an Android operating system, listening to an accessibility service event issued by the Android operating system, judging whether a user has triggered a target business in a business page of a self-owned software module of the cash register device according to the accessibility service event; if yes, interacting with the payment capability expansion device, so that the payment capability expansion device obtains capability requirement data adapted to the service side thereof, and executing a corresponding target business according to the capability requirement data.

[0011] The payment service processing device in the Android scenario provided by one or more embodiments of the present disclosure is applied to a system including a cash register device and a payment capability expansion device, and the device includes: a service trigger detection module, which, on the cash register device based on an Android operating system, listens to barrier-free service events issued by the Android operating system through an external software module provided by a service provider of the payment capability expansion device, and determines whether a user triggers a target service in a service page of a self software module of the cash register device according to the barrier-free service events; an adaptation capability requirement module, which, if yes, interacts with the payment capability expansion device through the external software module to enable the payment capability expansion device to obtain capability requirement data adapted to the service provider thereof; and a target service interaction execution module, which, on the payment capability expansion device, executes a corresponding target service according to the capability requirement data and returns execution result data obtained by executing the corresponding target service to the cash register device.

[0012] The payment service processing device in the Android scenario provided by one or more embodiments of the present disclosure 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: a listening and determining module, which, on the cash register device based on an Android operating system, listens to barrier-free service events issued by the Android operating system, and determines whether a user triggers a target service in a service page of a self software module of the cash register device according to the barrier-free service events; and an interaction module, which, if yes, interacts with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service provider thereof and execute a corresponding target service according to the capability requirement data.

[0013] The cash register device provided by one or more embodiments of the present disclosure includes a self software module and an external software module provided by a service provider of a payment capability expansion device; the self software module provides a service page to a user for interaction of the user in the service page; the external software module, on the cash register device based on an Android operating system, listens to barrier-free service events issued by the Android operating system, and determines whether the user triggers a target service in a service page of a self software module of the cash register device according to the barrier-free service events; if yes, the external software module interacts with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service provider thereof; and the self software module receives execution result data returned by the payment capability expansion device and obtained by executing a corresponding target service according to the capability requirement data.

[0014] The payment service processing device in the Android scenario provided by one or more embodiments of the present disclosure is applied to a system including a cash register device and a payment capability expansion device, and includes at least one processor and a memory in communication connection with the at least one processor. The memory stores instructions executable by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the following: on the cash register device based on an Android operating system, listening to an accessibility service event issued by the Android operating system through an external software module provided by a service side of the payment capability expansion device, judging whether a user triggers a target service in a business page of a self-owned software module of the cash register device according to the accessibility service event, if yes, interacting with the payment capability expansion device through the external software module to enable the payment capability expansion device to obtain capability requirement data adapted to the service side thereof, and on the payment capability expansion device, performing a corresponding target service according to the capability requirement data and returning execution result data to the cash register device.

[0015] The payment service processing device in the Android scenario provided by one or more embodiments of the present disclosure is applied to an external software module provided by a service side 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 at least one processor and a memory in communication connection with the at least one processor. The memory stores instructions executable by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the following: on the cash register device based on an Android operating system, listening to an accessibility service event issued by the Android operating system, judging whether a user triggers a target service in a business page of a self-owned software module of the cash register device according to the accessibility service event, if yes, interacting with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service side thereof and performing a corresponding target service according to the capability requirement data.

[0016] The above at least one technical solution adopted by one or more embodiments of the present disclosure can achieve the following beneficial effects: for a payment service provider of a payment capability expansion device, without the need for its customers (such as merchants, cash register service providers, etc.) to develop and transform the cash register device and its own software module (such as a SaaS cash register application), integrate a software development kit processing interface, etc., but only need to simply deploy an external software module provided by the payment service provider on the cash register device, connect the cash register device and the payment capability expansion device through a serial port or the like, and access the corresponding expansion payment support capability conveniently. The own software module also does not need to make cumbersome interface calls to the payment capability expansion device (such as an NFC payment device), and does not need to cooperate with the external software module for additional development, but actively listens to the barrier-free service events issued by the Android operating system of the cash register device according to the barrier-free service events, and speculates whether there is an opportunity for the payment capability expansion device to play a role according to the barrier-free service events, without using more cumbersome means such as coordinate position detection and screenshot analysis. If it is speculated that there is an opportunity, the own software module generates capability requirement data (such as interface call data) accordingly, instead of interacting with the payment capability expansion device, to help the cash register device and its own software module to realize the use of the expansion payment support capability. As can be seen, this scheme is mainly transformed and deployed by the payment service provider itself, and the customers can conveniently expand and access the payment capability expansion device without development and transformation, which is more friendly, and is also helpful for the payment service provider to expand the NFC payment business and other expansion payment businesses more widely. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the related art, the drawings needed to be used in the embodiments or related art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments described in the present disclosure, and other drawings can also be obtained by those skilled in the art without creative labor.

[0018] FIG. 1 is a flowchart of a payment business processing method in an Android scenario according to one or more embodiments of the present disclosure;

[0019] FIG. 2 is a flowchart of a labeling model preprocessing scheme according to one or more embodiments of the present disclosure;

[0020] FIG. 3 is a flowchart of a capability requirement data processing scheme according to one or more embodiments of the present disclosure;

[0021] FIG. 4 is a flowchart of a specific implementation of a payment business processing method in an Android scenario according to one or more embodiments of the present disclosure;

[0022] FIG. 5 is a flow diagram of a page layout patch processing scheme according to one or more embodiments of the present disclosure;

[0023] FIG. 6 is a flow diagram of another payment service processing method in an Android scenario according to one or more embodiments of the present disclosure;

[0024] FIG. 7 is a structural diagram of a payment service processing apparatus in an Android scenario according to one or more embodiments of the present disclosure;

[0025] FIG. 8 is a structural diagram of another payment service processing apparatus in an Android scenario according to one or more embodiments of the present disclosure;

[0026] FIG. 9 is a structural diagram of a cash register device according to one or more embodiments of the present disclosure;

[0027] FIG. 10 is a structural diagram of a payment service processing device in an Android scenario according to one or more embodiments of the present disclosure;

[0028] FIG. 11 is a structural diagram of another payment service processing device in an Android scenario according to one or more embodiments of the present disclosure. DETAILED DESCRIPTION

[0029] The embodiments of the present disclosure provide a payment service processing method, apparatus, device, storage medium, and cash register device in an Android scenario.

[0030] In order to enable persons skilled in the art to better understand the technical solutions in the present disclosure, the technical solutions in the embodiments of the present disclosure will be described clearly and completely below with reference to the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present application.

[0031] In view of the problems mentioned in the background, the present application considers that the service provider of the payment capability expansion device, referred to as the payment service party, actively uses the barrier-free auxiliary services provided by the Android operating system to flexibly and skillfully detect the decision model based on the pre-processing work such as page area marking (for understanding some key areas in the business page of the cashier software) to try to discover the use demand of the payment capability expansion device in real time without the development work such as interface modification of the cashier software. If the use demand of the payment capability expansion device is found, the payment service party will generate interface call data according to the decision result to help the cashier device and its cashier software use the capabilities of the payment capability expansion device, so that the merchant can conveniently and efficiently access the payment capability expansion device, and the merchant almost does not need to pay for the modification cost.

[0032] Based on such general idea, the scheme of the present application will be further described below.

[0033] Fig. 1 is a flowchart of a payment business processing method in an Android scenario provided by one or more embodiments of the present disclosure. The method is applied to a system including a cashier device (using an Android operating system) and a payment capability expansion device. In the system, the cashier device and the payment capability expansion device are connected by wired or wireless means, and the work of the cashier device is assisted by the payment capability expansion device. The execution subject of the flowchart can be the whole system, and the specific steps can be executed by the corresponding software and hardware modules in the system.

[0034] The cashier device and the payment capability expansion device are provided by different service parties (usually independent companies, and these companies can have no cooperation relationship). The cashier device is a basic device usually used by the merchant at the cashier counter, commonly a desktop or handheld Android POS machine, etc., which can support one or more basic payment methods, such as bank card payment, member card payment, and two-dimensional code payment, etc., but does not support some other relatively unconventional payment methods, such as NFC payment, facial recognition payment, palm print payment, etc. Therefore, the present application intends to expand other payment support capabilities. Taking the NFC payment device as the payment capability expansion device as an example, it can provide NFC payment support capability. The user can perform payment-related business based on near field communication by inducting the mobile terminal such as a smart phone or a smart watch supporting NFC function close to the payment capability expansion device. Other facial recognition payment devices and palm print payment devices can also be expanded in a similar way.

[0035] The flowchart in Fig. 1 includes the following steps.

[0036] S102: On the cash register device based on an Android operating system, through an external software module provided by a service party of the payment capability expansion device, an accessibility service event issued by the Android operating system is listened to, and it is judged whether a user (such as a cashier, a consumer, etc.) triggers a target service in a business page of a self-owned software module of the cash register device according to the accessibility service event.

[0037] In one or more embodiments of the present disclosure, in order to facilitate the distinction, the concepts of self-owned software module and external software module are used.

[0038] The self-owned software module refers to the basic cash register software installed on the cash register device, which is usually a SaaS cash register application provided by a certain SaaS application service provider. Some cash register software on the cash register device is self-contained, which usually belongs to a hardware and software integrated solution provided by the same service provider. Of course, the merchant can also select another service provider to provide cash register software according to the current cash register device and needs.

[0039] The external software module is provided by a service party of the payment capability expansion device (such as the payment service party mentioned above), and the corresponding software is pre-installed on the payment capability expansion device, which is also provided by the service provider. Since it is under the same research and development system of the service provider, the docking between the software and the external software module will be easier and lower in cost. The problem in the background art is essentially the docking between the software and the self-owned software module of the cash register device, which is not easy to implement due to technical differences, cost, etc. The present application mainly uses the external software module to do the work for the self-owned software module, realizes the docking with the payment capability expansion device and its software, and the self-owned software module itself does not need to actively cooperate with the external software module. The external software module creates the desired data for the self-owned software module, and basically does not affect the work of the self-owned software module.

[0040] The merchant can obtain the external software module from the service party of the payment capability expansion device in advance and deploy (such as install the corresponding software) it on the cash register device. The external software module is used to judge whether the user triggers a target service in the business page of the self-owned software module. The target service can be one or more services that the payment capability expansion device has the ability to at least partially execute, such as payment, member login, discount collection, etc. It should be noted that since the self-owned software module of the cash register device needs to be avoided for development and modification, the external software module does not directly access the interface of the self-owned software module to obtain the user's behavior in the business page of the self-owned software module, but is based on the accessibility service event listening and the pre-marking of the page area to infer the user's behavior.

[0041] For Android operating system, it can provide accessibility service for helping developers to facilitate some special users (such as visually impaired users, hearing impaired users), which can include AccessibilityService service. AccessibilityService service can run in the background, can receive some events issued by the operating system, called AccessibilityEvent event, that is, as the above-mentioned accessibility service event. Accessibility service event 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. AccessibilityService service can request to obtain the current active window and find the content therein. Various changes in the interface can generate a corresponding AccessibilityEvent event, and the system notifies AccessibilityService. Based on the service provided by the Android operating system, the application actively listens to AccessibilityEvent event through an external software module, and is sensitive to some expected AccessibilityEvent events, to instantly speculate whether there is an opportunity for the payment capability extension device to take action.

[0042] Of course, by analyzing the interface screenshot, detecting the interaction coordinates (such as by listening to global click events, keyboard events, etc.), it can also assist in determining whether the target business is triggered, but the device performance requirements are relatively high, which may occupy high CPU and memory resources, and the efficiency is relatively low, and the information obtained may not be detailed enough. It can be considered to be used under a non-Android operating system.

[0043] In contrast, based on the accessibility service event, more detailed user and interface interaction dynamic information can be efficiently obtained, and three AccessibilityEvent events are exemplarily given: for the "TYPE_VIEW_CLICKED" event, it can represent that the user clicks a specific view, such as a button, a checkbox, etc.; for the "TYPE_VIEW_TEXT_CHANGED" event, it can represent that the text in a specific view (such as a text box, etc.) has changed; for the "TYPE_NOTIFICATION_STATE_CHANGED" event, it can represent that the notification state in the notification bar has changed.

[0044] The external software module can apply to the Android operating system on the cash register device for obtaining the corresponding permission, and after obtaining the authorization, it can normally use the accessibility service.

[0045] To more reliably determine the detailed business meaning corresponding to the monitored barrier-free service event, to improve the judgment accuracy, a pre-built decision model can also be combined to assist in judgment. In one or more embodiments of the present disclosure, whether a user triggers a target business in a business page can be judged according to a barrier-free service event and a decision model, wherein the decision model is obtained by a service party of a payment capability expansion device according to page attention elements pre-marked by an own software module of a cash register device.

[0046] For ease of understanding, one or more embodiments of the present disclosure provide a flowchart of a marking model preprocessing scheme, see FIG. 2.

[0047] The flow in FIG. 2 includes the following steps.

[0048] S202: Before judging whether the user triggers a target business in a business page of the own software module of the cash register device according to the barrier-free 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 page names, buttons, and related text areas of interest.

[0049] Since a payment service party needs to serve multiple merchants, there will be multiple cash register devices in the system as a whole, and not all merchants will choose the same cash register software (which belongs to the above-mentioned own software module). The page layout of different cash register software may be different, which will affect the accuracy of subsequent judgment, so during preprocessing, different cash register software can be processed respectively. For example, taking cash register software as an example, in step S202, assuming that the cash register software is a SaaS cash register application, in the case of multiple SaaS cash register applications, page attention elements need to be marked for each SaaS cash register application respectively.

[0050] Page attention elements are elements related to target businesses, and the information provided may be helpful for subsequent judgment. For example, corresponding full-view business page names, window names, tab names, trigger buttons (such as payment buttons, member login buttons, etc., and the text on the buttons), text areas (such as display areas of amounts to be paid, member nickname display areas), cash register application identifiers, etc.

[0051] Through marking, the business meaning of these page attention elements can be determined, so that it is convenient for subsequent determination of whether a user has interacted with a page attention element (such as a payment button) or whether a certain page attention element (such as a text area for displaying the amount to be paid) has changed due to other actions of the user according to the page attention elements involved in the corresponding barrier-free service event.

[0052] Of course, in addition to the relatively reliable and accurate decision model, 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) matching is performed to determine whether the target business is triggered.

[0053] S204: Convert the marking data into a decision model reflecting the correspondence between the page attention elements and the business or accessibility service event.

[0054] The form of the decision model can be diverse, such as a simple model in the form of a simple data table, a more complex model such as a decision tree, a decision forest, or a machine learning model, etc.

[0055] In the case of multiple SaaS POS applications, multiple decision models can be obtained according to the respective targeted marking data, and in these decision models, the decision model corresponding to each SaaS POS application is selected, which helps to more accurately perform subsequent judgments.

[0056] S206: The decision model is delivered to the POS device where the corresponding SaaS POS application is located.

[0057] The decision model can be delivered to the external software module deployed on the POS device to determine whether the user has triggered the target business in the business page; or the decision model can be remotely called. After the preprocessing process in FIG. 2 is completed, the process in FIG. 1 can be executed.

[0058] The subsequent steps in FIG. 1 will be further described.

[0059] S104: If yes, the external software module interacts with the payment capability expansion device to make the payment capability expansion device obtain the capability requirement data adapted to its service provider.

[0060] If the target business itself has sufficient information to support correct execution, the corresponding capability requirement data can be generated locally or on the payment capability expansion device according to the target business. In addition, if necessary, auxiliary data can be obtained through methods such as listening to the voice broadcast of the POS device (if any), actively asking through synthesized voice, etc., and then generating the capability requirement data according to the target business and the auxiliary data.

[0061] In one or more embodiments of the present disclosure, the capability requirement data can be light data (such as a simple string, a simple message, or a small amount of text, etc.), in which case the capability requirement data is generated by the external software module and uploaded from the cash register device to the payment capability expansion device, so that the transmission capability requirement is low (such as transmission based on serial small instructions), which helps to improve efficiency. Conversely, if the transmission capability is strong, the screenshot image and service data can also be used as capability requirement data (relatively larger data amount), which is transmitted to the payment capability expansion device for further analysis and use by the payment capability expansion device.

[0062] S106: 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.

[0063] In one or more embodiments of the present disclosure, taking the NFC payment device as an example of the payment capability expansion device, after the NFC payment device obtains the capability requirement data, it can wait for the user (such as the consumer) to approach the NFC payment device with the mobile phone for inductive recognition. If the user does not have such an operation, 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 standby state after waiting for a timeout to wait for the next opportunity. If the user cooperates, the NFC payment device can execute the target business accordingly. Of course, the consumer can also perform NFC inductive recognition in advance, and then the cashier can operate on the cash register device, and then complete the execution of the target business under the cooperation of the cash register device and the NFC payment device.

[0064] Similarly, for face scanning payment devices, palm scanning payment devices, etc., the user is waited for to perform corresponding cooperation operations such as face scanning and palm scanning, and then the target business is executed.

[0065] It should be noted that the payment capability expansion device can only complete part of the work contained in the target business, for example, it can identify the user's payment code value as the execution result data returned to the cash register device, and then the cash register device will further complete the target business according to the execution result data. Conversely, if the payment capability expansion device basically completes the target business, the execution result data can only be a final result for feedback to the consumer.

[0066] By the method of FIG. 1, for the payment service party of the payment capability expansion device, the customers (such as merchants, cash register service providers, etc.) do not need to develop and transform the cash register device and its own software module (such as a SaaS cash register application), integrate a software development kit processing interface, etc., but only need to simply deploy an external software module provided by the payment service party on the cash register device, connect the cash register device with the payment capability expansion device through a serial port or the like, and access the corresponding expansion payment support capability conveniently. The own software module does not need to make cumbersome interface calls for the payment capability expansion device (such as an NFC payment device), and does not need to cooperate with the external software module for additional development, but actively listens to the barrier-free service event issued by the Android operating system of the cash register device, infers whether there is an opportunity for the payment capability expansion device to play a role according to the barrier-free service event, without using more cumbersome means such as coordinate position detection and screenshot analysis, and then generates capability requirement data (such as interface call data) accordingly if it is inferred that there is an opportunity, to replace the own software module and the payment capability expansion device for interaction, to help the cash register device and its own software module to realize the use of the expansion payment support capability. As can be seen, this scheme is mainly transformed and deployed by the payment service party itself, and the customers can conveniently expand and access the payment capability expansion device without development and transformation, which is more friendly, and is also helpful for the payment service party to expand the NFC payment business and other expansion payment businesses more widely.

[0067] Based on the method of FIG. 1, the present disclosure also provides some specific embodiments and extension schemes of the method, which will be described below.

[0068] Generally, the performance of the cash register device is stronger than that of the payment capability expansion device, especially the desktop cash register device. Therefore, the computing power of the cash register device is considered to be utilized to generate the capability requirement data by the external software module. Based on this, one or more embodiments of the present disclosure provide a flow diagram of a capability requirement data processing scheme, as shown in FIG. 3.

[0069] The flow in FIG. 3 includes the following steps.

[0070] S302: By the external software module, the target business and the barrier-free service provided by the Android operating system are determined to determine the service party of the payment capability expansion device, the interface to be called, and the input parameter adapted to the interface to be called.

[0071] Taking the examples of the payment and NFC payment device, the interface to be invoked is, for example, an interface for requesting the NFC payment device to read a payment code value based on near field communication induction from the consumer's mobile phone, and the input parameter includes, for example, the amount to be paid, so 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 amount to be paid can be authorized to be deducted from the current consumer's account.

[0072] In one or more embodiments of the present disclosure, the foreign software module can read the layout information globally through the barrier-free accessory service described above to obtain more detailed information such as the amount to be paid, and to determine the interface to be invoked and / or its input parameter more accurately and reliably for the target business.

[0073] S304: According to the interface to be invoked and the input parameter, interface invocation data is generated as capability requirement data.

[0074] In one or more embodiments of the present disclosure, the interface invocation data can be an interface invocation request conforming to the preset interface standard of the payment capability expansion device, so that the payment capability expansion device can use it directly; or the interface invocation data or other forms of capability requirement data can also be more lightweight description data, or even a simple natural language description, which can be further converted and used by the payment capability expansion device.

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

[0076] If the interface invocation data is an interface invocation request, the sending process is equivalent to the foreign software module invoking the interface provided by the software on the payment capability expansion device. Conversely, the sending process is only a relatively simple data transmission process. For such cases, for example, the foreign software module can generate a simple message (such as a few words, a short string, individual fields, etc.), and send the simple message 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 an interface invocation data adapted to its service side as capability requirement data. In this way, the requirements for the foreign software module and the transmission capability can be reduced, the impact on the cash register device will be further reduced, and the security can be improved.

[0077] According to the foregoing description, for the convenience of implementation, more intuitively, the disclosure one or more embodiments also provides a flow diagram of a specific implementation of a payment business processing method under the Android scenario, see Figure 4. In the scenario of Figure 4, the above-mentioned cash register device is specifically an Android POS machine (for example, using Android 4.0 or above system) used by a merchant offline store, and the self-owned software module is specifically a SaaS cash register application installed on the Android POS machine.

[0078] The scheme of Figure 4 includes two stages, a configuration preparation stage and an actual running stage.

[0079] The configuration preparation stage mainly includes the following steps: installing the free research application APK (belonging to the above-mentioned external software module) provided by the payment service party on the Android POS machine, and authorizing the permission of barrier-free service.

[0080] Run the automated collection marking software (which can also belong to the above-mentioned external software module) provided by the payment service party, and mark the payment, member, etc. according to the guide key page component name, button and text area, etc. in the SaaS cash register application.

[0081] Convert the marked data into business, coordinate, or event, etc. specific decision model, script data, etc. upload to the cloud, and store in association with the corresponding SaaS cash register application package name version, etc. identification, so as to accurately distribute.

[0082] The actual running stage mainly includes the following steps: distribute the marked decision model, script data, etc. to the corresponding SaaS cash register application on the Android POS machine, and run the background application automatically after starting, and deploy the listening judgment, etc. processing software (belonging to the above-mentioned external software module, which can include the previously deployed free research application APK) provided by the payment service party on the Android POS machine, and automatically start running, which can pre-process the system registry, device security software security issues, and obtain the corresponding self-starting permission.

[0083] Listen to the barrier-free service event, and through the callback page name, button name, text, etc. information combined with the decision model, transmit into the dynamic script to judge the payment, member login, etc. action, that is, determine whether the target business is triggered.

[0084] According to the payment, member login, etc. action, through the barrier-free service, the layout information can be globally read to obtain the amount or member information into specific interface call and input parameter data.

[0085] The Android POS machine transmits data to payment capability expansion devices such as NFC payment, face payment, and palm payment through small instructions by calling interfaces and input parameters through processing software deployed by a payment service provider, and then the device side performs payment and member login and other businesses. For the transmission mode here, for example, the two devices can be connected through a KD4 serial port to support bidirectional communication of small instructions between the two devices.

[0086] After the payment capability expansion device performs the target business such as payment and membership, the device simulates a human interface device through a human interface device (HID) protocol and backfills the obtained data (such as a business code value) corresponding to the target business into a corresponding input box of the SaaS cashier application of the Android POS machine, thereby realizing the business flow series connection between the SaaS cashier application and the software on the payment capability expansion device. The human interface device protocol supports one-way transmission mode of the payment capability expansion device to the Android POS machine, which facilitates efficient and direct backfilling of data without the need for the above-mentioned external software module.

[0087] In the foregoing scheme, the user directly triggers the target business through the original button area and the like of the self-owned software module. However, for some cashier applications, the prompt information of the area may be relatively strict, and the cashier application itself does not originally support payment methods such as NFC, face payment, and palm payment, and thus may cause ambiguity or conflict with the extended business field, thereby possibly causing user misunderstanding. To reduce the risk of such occurrence, the present application considers indirectly helping the user to correctly trigger the target business by additionally attaching a page layout patch, such as more explicitly prompting the association between the extended capability and the target business. In combination with FIG. 5, FIG. 5 is a flowchart of a page layout patch processing scheme provided by one or more embodiments of the present disclosure.

[0088] The flow in FIG. 5 includes the following steps.

[0089] S502: Generate a visual page layout patch according to the target business.

[0090] The page layout patch can be made in the form of a button or a block and the like, and belongs to a part of the external software module, and can be more correctly and reliably prompted for user interaction.

[0091] In one or more embodiments of the present disclosure, a business page simulation style learned according to a business page can be acquired; a visual style consistent with the business page is generated according to a target business and the business page simulation style, so as to facilitate subsequent supplementary layout and make the global appearance have coordination after the layout, so that the user is more likely to understand the page layout patch as a part of the business page originally.

[0092] S504: An additional local layer is generated for the business page, and a self-triggering control of the self-owned software module that matches the business page and the target business is determined, and the page layout patch is displayed in an area corresponding to the self-triggering control in the local layer.

[0093] Further, the page layout patch can be displayed in the local layer, and in order to prevent the interaction that may occur in other areas of the business page, the size of the page layout patch can be made as much as possible, and the range is avoided to be expanded unnecessarily, and the corresponding local layer can also be limited as much as possible in the range.

[0094] In addition to the manner of adding a layer, if the self-owned software module and the self-owned software module are authorized, the page layout patch can also be directly embedded in the business page through other manners such as front-end code injection, so that the integration effect is better.

[0095] In one or more embodiments of the present disclosure, since the present application has the ability and is more focused on listening to accessibility service events, it is expected that the page layout patch can also trigger the corresponding accessibility service event, of course, the page layout patch itself can be made into a triggerable control, but this way is not conducive to security and control cost. Therefore, the present application considers mainly using the page layout patch to guide the user to trigger the existing control in the self-owned software module (that is, the self-triggering control mentioned in step S504, such as a payment button, a login button, etc.), in order to achieve this purpose, the display position of the page layout patch can be deployed as in step S504.

[0096] S506: It is judged whether the user triggers the self-triggering control in the business page by triggering the page layout patch.

[0097] In one or more embodiments of the present disclosure, it can be determined whether the user is in the business page and triggers the page layout patch. Since the page layout patch can provide more accurate prompts, in the case of the demand for extended payment capabilities, the user can more accurately trigger the page layout patch. This action actually shows the user's intention to trigger the target business. Therefore, the external software module can determine that the user has triggered the target business or actually trigger the target business on behalf of the user.

[0098] Based on the above page layout patch deployment idea, if the user triggers the page layout patch, there is a high probability that the corresponding self-triggering control is also triggered. In this case, the external software module can determine that the user has triggered the target business based on the corresponding accessibility service event, without triggering the target business on behalf of the user again.

[0099] In one or more embodiments of the present disclosure, the page layout patch can be displayed in a first sub-region in the region corresponding to the self-triggering control in the local layer, and the local layer does not cover a second sub-region in the region of the self-triggering control. The first sub-region and the second sub-region are different regions. The first sub-region can have one or more (in the case of multiple, such as corresponding to different payment capability expansion devices, respectively). The second sub-region can have one or more (in the case of multiple, such as corresponding to different interaction channels other than payment capability expansion devices).

[0100] In this case, further, when determining whether the user is in the business page and triggers the page layout patch, it can be specifically implemented: determining whether the user in the business page triggers the first sub-region or the second sub-region (such as, it can be determined by analyzing the monitored accessibility service event, or determined according to other means of obtaining interaction coordinates); if the first sub-region is triggered, the corresponding target business is executed by interacting with the payment capability expansion device; if the second sub-region is triggered, the corresponding target business is executed through another interaction channel corresponding to the self-triggering control. The other interaction channel can be a payment method originally supported by the cash register device, such as scanning code payment, bank card payment, etc.

[0101] Whether the user triggers the first sub-region or the second sub-region, the self-triggering control can be indirectly triggered. Here, by distinguishing the triggering region, even if the same self-triggering control is triggered, different interaction channels can be adopted subsequently. In this way, the user can very conveniently and explicitly choose to use the extended payment method or the original payment method, and the operation habit of the user is not greatly affected. In addition, it can make the business interface more neat and beautiful, and also help to reduce the security risk of the local layer.

[0102] S508: Yes, it is determined that the user triggers the target service.

[0103] In this case, the determination result obtained in step S102 is yes, it can be seen that in this process, the self-owned software module also does not need to be developed and reformed, and the ease of use of the scheme for the user is further improved, not only that, the scheme can be more easily reused on other services or payment capability expansion devices through light adjustment of the page layout patch.

[0104] Fig. 1 is a whole that takes the cash register device and the payment capability expansion device as a whole, and describes from the perspective of the whole. For the payment service party, the modification mainly embodies the above-mentioned foreign software module, therefore, based on the same idea, from the perspective of the foreign software module, it is described again, referring to Fig. 6, Fig. 6 is a flowchart of another payment service processing method in an Android scenario provided by one or more embodiments of the present disclosure.

[0105] The payment service processing method in another Android scenario is applied to a foreign software module provided by a service party of a payment capability expansion device, and the foreign software module is pre-deployed on a cash register device. The flowchart in Fig. 6 includes the following steps.

[0106] S602: On the cash register device based on an Android operating system, listen to an accessibility service event issued by the Android operating system, and determine whether a user triggers a target service in a service page of a self-owned software module of the cash register device according to the accessibility service event.

[0107] S604: Yes, interact with the payment capability expansion device, so that the payment capability expansion device obtains capability requirement data adapted to the service party thereof, and executes a corresponding target service according to the capability requirement data.

[0108] The steps in Fig. 6 can be understood with reference to the foregoing description, and will not be described here.

[0109] Since the foreign software module is provided by the service party of the payment capability expansion device, it is not necessary to develop and reform the merchant, the cash register device and the cash register software, which is friendly to them, and helps to improve the enthusiasm of the merchant to expand the use of the payment capability expansion device.

[0110] Based on the same idea, the above-mentioned method corresponds to the device and equipment provided by one or more embodiments of the present disclosure, as shown in Figs. 7-11. The device and equipment can correspondingly execute the above-mentioned method and the related optional solutions.

[0111] Figure 7 is a structural schematic diagram of a payment service processing device in an Android scenario according to one or more embodiments of the present disclosure, applied to a system including a cash register device and a payment capability expansion device, and the device includes: a service trigger detection module 702, on the cash register device based on an Android operating system, through an external software module provided by a service side of the payment capability expansion device, listening to accessibility service events issued by the Android operating system, according to the accessibility service events, judging whether a user triggers a target service in a service page of a self-owned software module of the cash register device; an adaptation capability requirement module 704, 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 side; a target service interaction execution module 706, on the payment capability expansion device, according to the capability requirement data, executing a corresponding target service, and returning execution result data to the cash register device.

[0112] Optionally, the accessibility service event includes an AccessibilityEvent event issued based on an AccessibilityService service.

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

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

[0115] Optionally, the service trigger detection module 702, according to the accessibility service events and a decision model, judges whether the user triggers a target service in a service page of a self-owned software module of the cash register device, wherein the decision model is obtained by a service side of the payment capability expansion device according to a page attention element pre-marked for a self-owned software module of the cash register device.

[0116] Optionally, the self-owned software module of the cash register device includes a SaaS cash register application, and the SaaS cash register application and the payment capability expansion device are provided by different service sides.

[0117] Optionally, the system includes a plurality of cash register devices, and SaaS cash register applications of at least two cash register devices in the plurality of cash register devices are different and are respectively provided by different service sides.

[0118] Optionally, further comprising: a foreign software preprocessing module 708, before judging whether the user triggers a target service in a business page of a self-owned software module of the cash register device according to the barrier-free service event and the decision model, marking a page attention element for one or more SaaS cash register applications to obtain marking data, wherein the page attention element includes a page name, a button and a related text area; converting the marking data into a decision model reflecting the correspondence between the page attention element and the business or barrier-free service event; and issuing the decision model to the cash register device where the corresponding SaaS cash register application is located.

[0119] Optionally, the adaptive capability requirement module 704 generates capability requirement data adapted to the service side of the payment capability expansion device according to the target service; and sends the capability requirement data to the payment capability expansion device through the cash register device.

[0120] Optionally, the adaptive capability requirement module 704 determines an interface to be called adapted to the service side of the payment capability expansion device and an input parameter adapted to the interface to be called according to the target service and the barrier-free service provided by the Android operating system; and generates interface calling data as capability requirement data according to the interface to be called and the input parameter.

[0121] Optionally, the adaptive capability requirement module 704 generates a simple message according to the target service through the foreign software module, and sends the simple message 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 interface calling data adapted to the service side thereof as capability requirement data.

[0122] Optionally, the execution result data includes a business code value corresponding to the target service of the user; and the target service interaction execution module 706 backfills the business code value corresponding to the target service of the user into a corresponding input box of the self-owned software module of the cash register device through a human-computer interface device protocol.

[0123] Optionally, the business trigger detection module 702 generates a visual page layout patch according to a target service; generates an additional local layer for the business page, and displays the page layout patch in the local layer; judges whether a user triggers the page layout patch in the business page; if yes, automatically triggers a business control corresponding to the target service of the self-owned software module, and determines that the user triggers the target service.

[0124] Optionally, the business trigger detection module 702 determines a self-triggering control of the self-owned software module that matches the target business and the business page; displays the page layout patch in a region corresponding to the self-triggering control in the local layer; and determines whether the user triggers the self-triggering control by triggering the page layout patch in the business page.

[0125] Optionally, the business trigger detection module 702 displays the page layout patch in a first sub-region in the region corresponding to the self-triggering control in the local layer, the local layer does not cover a second sub-region in the region corresponding to the self-triggering control, the first sub-region and the second sub-region are different regions; determines whether the user triggers the first sub-region or the second sub-region in the business page; if the first sub-region is triggered, performs the corresponding target business by interacting with the payment capability expansion device; and if the second sub-region is triggered, performs the corresponding target business through another interaction channel corresponding to the self-triggering control.

[0126] Optionally, the business trigger detection module 702 obtains a business page simulation style learned according to the business page; and generates a page layout patch with visual style consistent with the business page according to the target business and the business page simulation style.

[0127] Optionally, the target business can be executed on the cash register device in a manner other than NFC; and the target business interaction execution module 706 executes the target business on the payment capability expansion device in a corresponding extended payment manner according to the capability requirement data.

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

[0129] FIG. 8 is a structural schematic diagram of a payment business processing apparatus in another Android scenario provided by one or more embodiments of the present disclosure, which is applied to an external software module provided by a service provider of a payment capability expansion device, the external software module is pre-deployed on a cash register device, and the apparatus includes a listening and determining module 802 that listens to an accessibility service event issued by an Android operating system on the cash register device based on the Android operating system, and determines whether a user triggers a target business in a business page of a self-owned software module of the cash register device according to the accessibility service event; and an interaction module 804 that, if so, interacts with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service provider thereof and perform a corresponding target business according to the capability requirement data.

[0130] FIG. 9 is a structural schematic diagram of a cash register device according to one or more embodiments of the present disclosure, the cash register device including a self-owned software module and a foreign software module provided by a service party of a payment capability expansion device; the self-owned software module provides a service page to a user for interaction of the user in the service page; the foreign software module listens to accessibility service events issued by an Android operating system on the cash register device based on the Android operating system, judges whether a target service is triggered by the user in the service page of the self-owned software module of the cash register device according to the accessibility service events, and if yes, interacts with the payment capability expansion device to make the payment capability expansion device obtain capability requirement data adapted to the service party thereof; the self-owned software module receives execution result data returned by the payment capability expansion device according to the capability requirement data and obtained by performing a corresponding target service.

[0131] FIG. 10 is a structural schematic diagram of a payment service processing device in an Android scenario according to one or more embodiments of the present disclosure, applied to a system including a cash register device and a payment capability expansion device, the payment service processing device in the Android scenario including at least one processor and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions are executed by the at least one processor to enable the at least one processor to perform: listening to accessibility service events issued by an Android operating system on the cash register device based on the Android operating system through a foreign software module provided by a service party of the payment capability expansion device, judging whether a target service is triggered by a user in a service page of a self-owned software module of the cash register device according to the accessibility service events; if yes, interacting with the payment capability expansion device through the foreign software module to make the payment capability expansion device obtain capability requirement data adapted to the service party thereof; performing a corresponding target service on the payment capability expansion device according to the capability requirement data, and returning execution result data to the cash register device.

[0132] FIG. 11 is a structural schematic diagram of a payment service processing device in another Android scenario provided by one or more embodiments of the present disclosure, applied to an external software module provided by a service side of a payment capability expansion device, the external software module being pre-deployed on a cash register device, the payment service processing device in the Android scenario comprising: at least one processor; and a memory in communication connection with 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 perform: listening, on the cash register device based on an Android operating system, to an accessibility service event issued by the Android operating system, judging, according to the accessibility service event, whether a user triggers a target service in a service page of a self-owned software module of the cash register device; if yes, interacting with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service side thereof and performing a corresponding target service according to the capability requirement data.

[0133] Based on the same idea, one or more embodiments of the present disclosure also provide a non-volatile computer storage medium, applied to a system comprising a cash register device and a payment capability expansion device, the medium storing computer executable instructions, the computer executable instructions being configured to: listen, on the cash register device based on an Android operating system, to an accessibility service event issued by the Android operating system through an external software module provided by a service side of the payment capability expansion device, judge, according to the accessibility service event, whether a user triggers a target service in a service page of a self-owned software module of the cash register device; if yes, interact, through the external software module, with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service side thereof; and perform, on the payment capability expansion device, a corresponding target service according to the capability requirement data and return execution result data to the cash register device.

[0134] One or more embodiments of the present disclosure also provide another non-volatile computer storage medium, applied to an external software module provided by a service side of a payment capability expansion device, the external software module being pre-deployed on a cash register device, the medium storing computer executable instructions, the computer executable instructions being configured to: listen, on the cash register device based on an Android operating system, to an accessibility service event issued by the Android operating system, judge, according to the accessibility service event, whether a user triggers a target service in a service page of a self-owned software module of the cash register device; if yes, interact with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service side thereof and perform a corresponding target service according to the capability requirement data.

[0135] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, 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., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0136] The controller can be implemented in any suitable way, for example, the controller can take the form of a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, 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, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that, in addition to being implemented in pure computer readable program code, the controller can also be implemented to perform the same functions in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers, etc. by logically programming the method steps. Therefore, such a controller can be considered as a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can even be considered as both a software module implementing a method and a structure within a hardware component.

[0137] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can 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.

[0138] For the sake of description, the above apparatuses are described in various units by functions respectively. Of course, the functions of each unit can be implemented in the same or multiple software and / or hardware in implementing the present disclosure.

[0139] Those skilled in the art will understand that the embodiments of the present disclosure can be provided as a method, a system or a computer program product. Therefore, the embodiments of the present disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0140] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0141] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks.

[0142] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0143] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0144] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, for storing instructions and data used by one or more of the components of the computing device. The memory can further include non-volatile memory, such as read-only memory (ROM), electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other non-volatile memory.

[0145] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The 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 technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0146] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not only include those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0147] The present disclosure can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like, which perform particular tasks or implement particular abstract data types. The present disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communication network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including storage devices.

[0148] The various embodiments in the present disclosure are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the difference from other embodiments. In particular, for the device, apparatus, 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 part of the method embodiment.

[0149] The above describes particular embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown or sequential order in order to achieve the desired results. In some implementations, multitasking and parallel processing can be advantageous or necessary.

[0150] The above descriptions merely serve as one or more embodiments of the present disclosure and are not intended to limit the present disclosure. One or more embodiments of the present disclosure can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of one or more embodiments of the present disclosure should be included in the scope of claims of the present disclosure.

Claims

1. A payment service processing method in an Android scenario, applied to a system comprising a cash register device and a payment capability expansion device, the method comprising: on the cash register device based on an Android operating system, listening to accessibility service events issued by the Android operating system through an external software module provided by a service side of the payment capability expansion device, and determining whether a user triggers a target service in a service page of a self-owned software module of the cash register device according to the accessibility service events; if yes, interacting with the payment capability expansion device through the external software module to enable the payment capability expansion device to obtain capability requirement data adapted to the service side thereof; on the payment capability expansion device, performing a corresponding target service according to the capability requirement data, and returning execution result data to the cash register device.

2. The method of claim 1, the accessibility service event comprising: based on AccessibilityEvent events issued by an AccessibilityService service.

3. The method of claim 1, wherein the accessibility service events represent at least one of the following state changes of a user interface on the cash register device: focus change, input content change, button click.

4. The method of claim 1, wherein the payment capability expansion device comprises at least one of the following: an NFC payment device, a face payment device, and a palm payment device.

5. The method of claim 1, wherein the determining whether the user triggers a target service in a service page of a self-owned software module of the cash register device according to the accessibility service events specifically comprises: determining whether the user triggers a target service in a service page of a self-owned software module of the cash register device according to the accessibility service events and a decision model, wherein the decision model is obtained by a service side of the payment capability expansion device according to page attention elements pre-marked for the self-owned software module of the cash register device.

6. The method of claim 5, wherein the self-owned software module of the cash register device comprises a SaaS cash register application, and the SaaS cash register application and the payment capability expansion device are provided by different service sides.

7. The method of claim 6, wherein the system comprises a plurality of cash register devices, and SaaS cash register applications of at least two cash register devices in the plurality of cash register devices are different and are provided by different service sides, respectively.

8. The method of claim 6, wherein before the determining whether the user triggers a target service in a service page of a self-owned software module of the cash register device according to the accessibility service events and a 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 comprise a page name, a button, and a related text area of interest; converting the marking data into a decision model reflecting a correspondence between the page attention elements and services or accessibility service events; and downloading the decision model to a cash register device on which a corresponding SaaS cash register application is located.

9. The method of claim 1, wherein the interacting with the payment capability extension device to cause the payment capability extension device to obtain capability requirement data adapted to a service provider thereof comprises: generating, according to the target service, capability requirement data adapted to the service provider of the payment capability extension device; and sending, by the cash register device, the capability requirement data to the payment capability extension device.

10. The method of claim 9, wherein the generating, according to the target service, capability requirement data adapted to the service provider of the payment capability extension device comprises: determining, according to the target service and accessibility services provided by the Android operating system, an interface to be invoked adapted to the service provider of the payment capability extension device, and input parameters adapted to the interface to be invoked; and generating, according to the interface to be invoked and the input parameters, interface invocation data as the capability requirement data.

11. The method of claim 1, wherein the interacting with the payment capability extension device to cause the payment capability extension device to obtain capability requirement data adapted to a service provider thereof comprises: generating, by the foreign software module, a simple message according to the target service, and sending, by the cash register device, the simple message to the payment capability extension device through serial communication, to cause the payment capability extension device to convert the simple message into interface invocation data adapted to the service provider thereof as the capability requirement data.

12. The method of claim 1, wherein the determining whether the user triggers a target service in the service page comprises: generating a visual page layout patch according to the target service; generating an additional local layer for the service page, and displaying the page layout patch in the local layer; determining whether the user triggers the page layout patch in the service page; and if so, automatically triggering a service control of the native software module corresponding to the target service, and determining that the user triggers the target service.

13. The method of claim 12, wherein the displaying the page layout patch in the local layer comprises: determining a native trigger control of the native software module matched with the target service and the service page; and displaying the page layout patch in a region of the local layer corresponding to the native trigger control.

14. The method of claim 13, wherein the determining whether the user triggers the page layout patch in the service page comprises: determining whether the user triggers the native trigger control in the service page by triggering the page layout patch.

15. The method of claim 14, wherein the displaying the page layout patch in the local layer corresponding to the native trigger control comprises: displaying the page layout patch in a first sub-region of the region of the local layer corresponding to the native trigger control, the local layer not covering a second sub-region of the region of the native trigger control, the first sub-region being different from the second sub-region. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ The judgment whether the user is in the business page triggers the page layout patch, specifically comprising: Judging whether the user in the business page triggers the first sub-area or the second sub-area; If the first sub-area is triggered, the corresponding target business is executed by interacting with the payment capability expansion device; If the second sub-area is triggered, the corresponding target business is executed through another interaction channel corresponding to the self-triggering control.

15. The method of claim 12, wherein the visual page layout patch is generated according to the target business, specifically comprising: Obtaining a business page simulation style learned according to the business page; Generating a visual page layout patch with consistency with the business page according to the target business and the business page simulation style.

16. A payment business processing method in an Android scenario, applied to an external software module provided by a service side 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 an Android operating system, listening to accessibility service events issued by the Android operating system, and judging whether a user triggers a target business in a business page of a self software module of the cash register device according to the accessibility service events; If yes, interacting with the payment capability expansion device to make the payment capability expansion device obtain capability requirement data adapted to the service side thereof, and executing the corresponding target business according to the capability requirement data.

17. A payment business processing device in an Android scenario, applied to a system comprising a cash register device and a payment capability expansion device, the device comprising: A business trigger detection module, on the cash register device based on an Android operating system, listening to accessibility service events issued by the Android operating system through an external software module provided by a service side of the payment capability expansion device, and judging whether a user triggers a target business in a business page of a self software module of the cash register device according to the accessibility service events; An adaptive capability requirement module, if yes, interacting with the payment capability expansion device through the external software module to make the payment capability expansion device obtain capability requirement data adapted to the service side thereof; A target business interaction execution module, on the payment capability expansion device, executing the corresponding target business according to the capability requirement data, and returning execution result data to the cash register device.

18. The apparatus of claim 17, the accessibility service event comprising: Based on the AccessibilityService service issued AccessibilityEvent event.

19. The device of claim 17, wherein the accessibility service event represents at least one of the following state changes of a user interface on the cash register device: focus change, input content change, button click.

20. The device of claim 17, wherein the payment capability expansion device comprises at least one of the following: NFC payment device, face payment device, palm payment device.

21. The apparatus of claim 17, wherein the service trigger detection module determines whether the user triggered a target service in a service page of a self-owned software module of the cash register device based on the barrier-free service event and a decision model. The decision model is obtained by a service provider of the payment capability expansion device according to page attention elements pre-labeled by a self-owned software module of the POS device.

22. The apparatus of claim 21, wherein the self-owned software module of the POS device comprises a SaaS POS application, and the SaaS POS application is provided by a different service provider than the payment capability expansion device.

23. The apparatus of claim 22, further comprising: a foreign software preprocessing module configured to, before the determining whether the user triggers a target service in a service page of the self-owned software module of the POS device according to the accessibility service event and a decision model, label page attention elements for one or more SaaS POS applications to obtain labeling data, wherein the page attention elements comprise a page name, a button, and a related text area of interest; convert the labeling data into a decision model reflecting a correspondence between the page attention elements and the service or the accessibility service event; and distribute the decision model to a POS device where the corresponding SaaS POS application is located.

24. A POS device comprising a self-owned software module and a foreign software module provided by a service provider of a payment capability expansion device; the self-owned software module configured to provide a service page to a user for interaction by the user in the service page; the foreign software module configured to, on the POS device based on an Android operating system, listen to an accessibility service event issued by the Android operating system, and determine whether the user triggers a target service in a service page of the self-owned software module of the POS device according to the accessibility service event; if so, interact with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service provider thereof; and the self-owned software module configured to receive execution result data returned by the payment capability expansion device according to the capability requirement data for performing a corresponding target service.

25. A payment service processing device in an Android scenario, applied to a foreign software module provided by a service provider of a payment capability expansion device, the foreign software module being pre-deployed on a POS device, the payment service processing device in the Android scenario comprising: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: on the POS device based on an Android operating system, listening to an accessibility service event issued by the Android operating system, and determining whether a user triggers a target service in a service page of a self-owned software module of the POS device according to the accessibility service event; if so, interacting with the payment capability expansion device to enable the payment capability expansion device to obtain capability requirement data adapted to the service provider thereof, and performing a corresponding target service according to the capability requirement data.

Images