WO2018001272A1 - Management method and system for android payment plugin - Google Patents

Abstract

Disclosed in the present invention is a management method for an Android payment plugin; the method comprising: a payment platform generating a configuration file for a transaction interface and a transaction process, and submitting the configuration file to an intermediate service layer; a front-end application registering transaction types supported thereby, and calling back to the intermediate service layer; the intermediate service layer obtaining a user transaction channel, and according to the configuration file, calling a corresponding transaction interface of the payment platform, thus completing a transaction. By means of said method, the present invention may achieve high degree coupling between service functions and transaction functions, thus eliminating a workload of a front-end platform and reducing investment costs for future expansion and maintenance.

Description

 Title: Management method and system for Android payment plug-in

 [0001] The present invention relates to the field of Android payment technologies, and in particular, to a management method and system for an Android payment plug-in.

 Background technique

 [0002] In the past, an APP with payment function was issued, and the sender usually integrated these payment functions directly in the APP, and the business function and the payment function were combined and interacted. In the era of UnionPay card payment as the main trading platform, this approach can barely solve the bursting demand. However, as payment models such as WeChat and Alipay have gradually become popular payment channels for ordinary consumers and merchants, there are more and more payment platforms that APP needs to dock. If it is still in the past, it will be difficult, timely, maintenance, etc. The complexity grows geometrically.

 [0003] Android smartphones typically have a number of apps installed, all of which focus on implementing their main features, and they usually don't focus on secondary features to provide a good experience for the user. For example, a dating software, which focuses on chatting between friends, dynamic sharing, and so on. After implementing these main functions, the APP also implements the location sharing function of the friends. According to the general practice, the APP needs to integrate the functions of the map, and this will take a lot of manpower and resources.

 [0004] The above manner has the following disadvantages:

 [0005] Disadvantage 1: In addition to supporting traditional UnionPay card payment channels, APPs with payment functions must support emerging payment platforms. In addition to focusing on business functions, senders must pay attention to multi-platform access, including platforms. Inter-interface calls, processes, data messages, etc.

[0006] Disadvantages 2: Later expansion and maintenance require a lot of manpower, and the results are often poor.

[0007] Disadvantages 3: Business functions and payment functions are highly coupled and cannot be easily ported to new APPs.

 technical problem

 [0008] The technical problem to be solved by the present invention is: providing a mechanism for realizing the interaction between the front-end application and the financial transaction platform, so that the front-end bursting personnel do not have to pay attention to the API and financial transaction flow of the payment platform.

 Problem solution

Technical solution [0009] In order to solve the above technical problem, the technical solution adopted by the present invention is: Providing a management method of an Android payment plug-in, including:

[0010] The payment platform generates a configuration file for the transaction interface and the transaction process, and submits it to the intermediate service layer;

[0011] The front-end application registers its own supported transaction type callback to the intermediate service layer;

 [0012] The intermediate service layer acquires a user transaction channel, and invokes a corresponding payment platform transaction interface according to the configuration file to complete the transaction.

 [0013] In order to solve the above problem, the present invention further provides a management system for an Android payment plug-in, including a payment platform, an intermediate service layer, and a front-end application, where:

[0014] the payment platform is configured to generate a configuration file for the transaction interface and the transaction process, and submit to the intermediate service layer;

[0015] The front-end application is used to register a transaction type supported by itself to call back to the intermediate service layer;

[0016] The intermediate service layer is configured to acquire a user transaction channel, and invoke a corresponding payment platform transaction interface according to the configuration file to complete the transaction.

 Advantageous effects of the invention

 Beneficial effect

 [0017] The beneficial effects of the present invention are as follows: Different from the prior art, the present invention configures the transaction interface and the process into a file form, and submits it to the intermediate service layer. After the intermediate service layer obtains the transaction channel at the front end, the invention is called according to the configuration file. Corresponding transaction interface, and complete the transaction. Through the above manner, the invention can effectively eliminate the high coupling of the business function and the transaction function, eliminate the workload of the front-end platform, and reduce the input cost of the later expansion maintenance.

 Brief description of the drawing

 DRAWINGS

 1 is a schematic diagram of an intermediate service layer and a payment calling API in a specific embodiment of the present invention;

2 is a schematic diagram of an operation process of an intermediate service layer in a specific embodiment of the present invention.

detailed description

[0020] In order to explain the technical content, the objects and effects achieved by the present invention in detail, the following description will be described in conjunction with the accompanying drawings. [0021] The most critical idea of the present invention is: Calling the front-end API and interface in the payment intermediate service layer to implement an organic combination of interaction mechanisms.

[0022] Embodiment 1 of the present invention provides a method for managing an Android payment plug-in, including:

[0023] The payment platform generates a configuration file for the transaction interface and the transaction process, and submits it to the intermediate service layer;

[0024] The front-end application registers its own supported transaction type callback to the intermediate service layer;

 [0025] The intermediate service layer acquires a user transaction channel, and invokes a corresponding payment platform transaction interface according to the configuration file to complete the transaction.

 [0026] Different from the prior art, the present invention configures the transaction interface and the process into a file format and submits it to the intermediate service layer. After the intermediate service layer obtains the transaction channel at the front end, the corresponding transaction interface is invoked according to the configuration file, and is completed. transaction. Through the above manner, the present invention can achieve high degree of coupling between business functions and transaction functions, eliminate the workload of the front-end platform, and reduce the input cost of post-expansion maintenance.

 [0027] wherein, the payment platform forms an interface configuration file for each transaction type interface according to the intermediate service layer specification label, and submits it to the intermediate service layer. The intermediate service layer loads the configuration file after startup.

 [0028] The intermediate service layer detects whether the intermediate service layer supports more than one channel of the transaction type after acquiring the user transaction channel;

 [0029] If yes, displaying a channel selection list and obtaining a transaction channel selected by the user;

[0030] Otherwise, the transaction channel selected by the user is directly obtained.

 [0031] The intermediate service layer completes the transaction by calling the corresponding payment platform API according to the selected transaction channel, wherein the calling process is defined according to the process configuration file label;

[0032] The intermediate service layer invokes the payment platform API to determine whether the front-end application needs to participate in execution;

[0033] If yes, the transaction is implemented by calling back the transaction type to the front-end application;

[0034] Otherwise, the payment platform API is directly called to complete the transaction.

 [0035] After completing the transaction, the intermediate service layer returns the transaction result to the front-end application through the transaction listener.

[0036] Correspondingly, the second embodiment of the present invention provides a management system for an Android payment plug-in, which includes a payment platform, an intermediate service layer, and a front-end application, where:

[0037] the payment platform is configured to generate a configuration file for the transaction interface and the transaction process, and submit to the intermediate service layer;

[0038] the front-end application is used to register a transaction type supported by itself to call back to the intermediate service layer;

[0039] The intermediate service layer is configured to acquire a user transaction channel, and invoke a corresponding payment platform transaction connection according to the configuration file. Mouth, complete the transaction.

 [0040] wherein, the payment platform forms an interface configuration file for each transaction type interface according to the intermediate service layer specification label, and submits it to the intermediate service layer. The intermediate service layer loads the configuration file after startup.

 [0041] After obtaining the user transaction channel, the intermediate service layer detects whether the intermediate service layer supports more than one channel of the transaction type;

 [0042] If yes, displaying a channel selection list and obtaining a transaction channel selected by the user;

[0043] Otherwise, the transaction channel selected by the user is directly obtained.

 [0044] The intermediate service layer completes the transaction by calling the corresponding payment platform API according to the selected transaction channel, wherein the calling process is defined according to the process configuration file label;

[0045] The intermediate service layer invokes the payment platform API to determine whether the front-end application needs to participate in execution;

[0046] If yes, the transaction is implemented by calling back the transaction type to the front-end application;

[0047] Otherwise, the payment platform API is directly called to complete the transaction.

 [0048] After completing the transaction, the intermediate service layer returns the transaction result to the front-end application through the transaction listener

[0049] For ease of understanding, the following description will be made by way of a specific embodiment in conjunction with FIGS. 1 and 2.

[0050] The present invention consists of a payment intermediate service layer and a payment invocation API, as shown in FIG.

[0051] The present invention is based on the componentized design concept, which separates the business function from the payment function, wherein the payment function resides in the system in the form of a component, which provides a series of transaction interfaces to realize interaction with the business function. Due to the various platform interfaces, there are huge differences in the process, which makes the front-end bursting more difficult. Therefore, if an arbitration mechanism is added between the two to solve the interface process differences of various platforms and provide a unified front-end application access interface, the front-end application bursting efficiency will be greatly improved, and the function decoupling and Reuse. The intermediate service layer plays the role of intermediate arbitration, which provides a set of interaction mechanisms to organically combine the two.

[0052] The basic principle of the intermediate service layer is to configure the change of the transaction interface and the process in the form of a file, and provide only a unified API for the front-end burst. Suppose there is such a scenario: Platform A supports transaction T (such as consumption). To complete T transaction, three interface implementations need to be called. The calling sequence is al-a2-a3, and platform B also supports transaction T, but the transaction needs to be completed. Call four interfaces, the calling order is bl-b2-b3-b4. It can be seen that the interface and process differences cannot be directly blocked, that is, the front-end call cannot implement transactions based on the A platform and the B platform by the same set of interfaces and processes. In addition to this, the transaction of platform A needs to call the a2 interface. The front-end application participates in the exchange of data, while the B-platform does not require the front-end application to participate in any action. Such scenes often appear in the interactive process of functional componentization. The intermediate service layer saves the al, 22, a3, and bl, b2, b3, and b4 interfaces and processes in TA and TB file configurations. The changed interface and process are configured to form a series of regular label items, and the intermediate service layer interfaces the front end to initiate a transaction, and the current end application connects to the intermediate service layer through the interface, the incoming platform identifier, and the transaction type. The intermediate service layer reads the execution steps of the transaction from the configuration file, invokes the platform transaction interface to complete the transaction, and then returns the transaction result to the front-end application. As mentioned above, in the implementation of the transaction process, the front-end application needs to participate in data exchange. To implement this function, the intermediate service layer provides a registration callback interface, which is used to implement the interaction function between the front end and the platform. It is worth noting that this interaction is different from the direct interaction between the front-end application and the platform. Direct interaction requires the front-end application to know the transaction process, which is a two-way operation process. Through the registration callback interface provided by the intermediate service layer, the front-end application only needs to passively implement the interaction, that is, when the front-end application implements the interaction, the intermediate service layer initiates the initiative, such as AC1~AC3, and BC1~BC4 are only one-way operations.

 [0053] The intermediate service layer process is shown in FIG. 2, and specifically includes the following steps:

 [0054] SI (loadTransactionXml): The third-party payment platform forms an interface configuration file for each transaction type interface according to the middle layer specification label, and submits it to the intermediate service layer. The intermediate service layer loads these configuration files after startup;

 [0055] S2 (registerPuppets): The front-end application registers its own supported transaction type callbacks (eg consumption Puppet)

) to the intermediate service layer;

 [0056] S3 (showTransactionChannel): If the intermediate service layer supports multiple channels of the transaction type (such as WeChat, Alipay, and UnionPay platform), the channel selection list is popped up to allow the user to select the desired channel transaction;

 [0057] S4 (doTransaction): The intermediate service layer invokes the corresponding third-party platform AP I to complete the transaction according to the selected transaction channel, and the calling process is defined according to the process configuration file label; specifically, the call of the payment platform API is configured according to the corresponding process. The file is carried out. The process configuration file uses a series of tags to define the conditions of the API call and the result of the call. The result of the call defines how to select the API for the next call;

[0058] S5 (callback): In the process of calling the third-party platform API by the intermediate service layer, the front-end application needs to participate in the execution, and the front-end application is implemented by Puppet callback; [0059] S6 (OnTransactionListener): The intermediate service layer returns the transaction result to the front-end application through the transaction listener.

 [0060] Therefore, the present invention is applicable to a third-party merchant application to conveniently access each payment platform, and the merchant application sender does not need to pay attention to the transaction process of each platform, the difference of interfaces, and realize the non-differential docking of each platform. The present invention completely separates business functions from payment functions in a modularized manner and provides a solution for interaction between applications. In addition, the intermediate service layer shields the differences between the interface and the process of each platform. In the operation involving the interaction between the service function and the payment function, the middle layer is completed by a callback mechanism, and the invention can realize the expansion of the new payment platform very conveniently.

 The above are only the embodiments of the present invention, and are not intended to limit the scope of the present invention, and equivalent transformations made by the description of the present invention and the contents of the drawings may be directly or indirectly applied in the related technical fields. The scope of the invention is included in the scope of the patent protection of the present invention.

 [0062]

[0063]

Claims

Claim  [Claim 1] A method for managing an Android payment plug-in, comprising:  The payment platform generates a configuration file for the transaction interface and the transaction process, and submits to the intermediate service layer, and the transaction type supported by the front-end application registration is called back to the intermediate service layer;  The intermediate service layer obtains the user transaction channel, and invokes the corresponding payment platform transaction interface according to the configuration file to complete the transaction.  The method for managing an Android payment plug-in according to claim 1, wherein the payment platform forms an interface configuration file for each transaction type interface according to an intermediate service layer specification tag, and submits it to the intermediate service layer, and the intermediate service layer is loaded at the startup. The configuration file. The method for managing the Android payment plug-in according to claim 1, wherein the step of obtaining the user transaction channel by the intermediate service layer is specifically:  Detect whether there are more than one channel for the intermediate service layer to support the transaction type;  If yes, the channel selection list is displayed, and the transaction channel selected by the user is obtained; otherwise, the transaction channel selected by the user is directly obtained.  The management method of the Android payment plug-in according to claim 1, wherein the intermediate service layer calls the corresponding payment platform API to complete the transaction according to the selected transaction channel, and the calling process is defined according to the process configuration file label;  The intermediate service layer invokes the payment platform API to determine whether the front-end application is required to participate in the execution; if so, the transaction is implemented by calling back the transaction type to the front-end application;  Otherwise, the payment platform API is directly called to complete the transaction.  The method for managing an Android payment plug-in according to claim 1, wherein after the transaction is completed, the intermediate service layer returns the transaction result to the front-end application through the transaction listener. A management system for an Android payment plug-in, comprising: a payment platform, an intermediate service layer, and a front-end application, wherein: The payment platform is configured to generate a configuration file for the transaction interface and the transaction process, and submit it to the intermediate service front-end application for registering the transaction type supported by itself to call back to the intermediate service layer; The intermediate service layer is used to obtain a user transaction channel, and the corresponding payment platform transaction interface is called according to the configuration file to complete the transaction.  [Claim 7] The management system of the Android payment plug-in according to claim 6, wherein the payment platform forms an interface configuration file for each transaction type interface according to the intermediate service layer specification label, and submits it to the intermediate service layer, the intermediate service. The layer loads the configuration file at startup.  [Claim 8] The management system of the Android payment plug-in according to claim 6, wherein the intermediate service layer acquires the user transaction channel, specifically for:  Detect whether there are more than one channel for the intermediate service layer to support the transaction type;  If yes, the channel selection list is displayed, and the transaction channel selected by the user is obtained; otherwise, the transaction channel selected by the user is directly obtained.  [Claim 9] The management system of the Android payment plug-in according to claim 6, wherein the intermediate service layer is configured to complete the transaction according to the selected payment platform API according to the selected transaction channel, wherein the calling process is defined according to the process configuration file label. ;  The intermediate service layer invokes the payment platform API to determine whether the front-end application is required to participate in the execution; if so, the transaction is implemented by calling back the transaction type to the front-end application;  Otherwise, the payment platform API is directly called to complete the transaction.  [Claim 10] The management system of the Android payment plug-in according to claim 6, wherein after the transaction is completed, the intermediate service layer returns the transaction result to the front-end application through the transaction listener.