CN114217890A

CN114217890A - Interface control method and device, aggregation payment platform and storage medium

Info

Publication number: CN114217890A
Application number: CN202111371870.6A
Authority: CN
Inventors: 刘忠; 付福军
Original assignee: Shenzhen Youke Yunlian Technology Co ltd; Shenzhen Ucloudlink New Technology Co Ltd
Current assignee: Shenzhen Youke Yunlian Technology Co ltd; Shenzhen Ucloudlink New Technology Co Ltd
Priority date: 2021-11-18
Filing date: 2021-11-18
Publication date: 2022-03-22

Abstract

The application is applicable to the technical field of aggregate payment, and provides an interface control method, an interface control device, an aggregate payment platform and a storage medium, wherein the interface control method comprises the following steps: if a product payment request sent by a client is received, determining a target payment mode of the client based on the product payment request; based on the target payment mode, controlling the client to jump from a current interface to a first payment interface, wherein the first payment interface is a webpage payment interface corresponding to the target payment mode; acquiring the client type of the client; and controlling the client to jump from the first payment interface to a second payment interface according to the client type, wherein the second payment interface is the payment interface of different client types corresponding to the target payment mode. The scheme can respond to the target payment mode selected by the client and provide a corresponding payment interface according to the client type of the client.

Description

Interface control method and device, aggregation payment platform and storage medium

Technical Field

The application belongs to the technical field of aggregate payment, and particularly relates to an interface control method, an interface control device, an aggregate payment platform and a storage medium.

Background

The online payment refers to a business in which a bank provides online fund settlement services to a seller and a buyer when the seller and the buyer perform transactions through an e-commerce website on the internet. With the rapid development of third-party payment software, online payment becomes a ring with the largest market scale in mobile payment, when a merchant is connected with the third-party payment software, different payment channels (such as payment treasure, WeChat, Unionpay, foreign paypal payment and the like) need to be connected according to different connected third-party payment software, the same channel displays different interfaces needing to be connected at different clients (such as mobile phone software, computer websites, applets, public numbers and the like), and different payment interfaces are displayed by calling the interfaces.

Disclosure of Invention

The embodiment of the application provides an interface control method, an interface control device, an aggregation payment platform and a storage medium, and can provide a payment interface corresponding to a payment mode and a client after the payment mode is combined with the client when different payment modes and different clients perform online payment services.

A first aspect of an embodiment of the present application provides an interface control method, where the interface control method includes:

if a product payment request sent by a client is received, determining a target payment mode of the client based on the product payment request;

based on the target payment mode, controlling the client to jump from a current interface to a first payment interface, wherein the first payment interface is a webpage payment interface corresponding to the target payment mode;

acquiring the client type of the client;

and controlling the client to jump from the first payment interface to a second payment interface according to the client type, wherein the second payment interface is the payment interface of different client types corresponding to the target payment mode.

A second aspect of an embodiment of the present application provides an interface control apparatus, including:

the payment determining module is used for determining a target payment mode of the client based on a product payment request sent by the client if the product payment request is received;

the first skip control module is used for controlling the client to skip from a current interface to a first payment interface based on the target payment mode, wherein the first payment interface is a webpage payment interface corresponding to the target payment mode;

the acquisition module is used for acquiring the client type of the client;

and the second skip control module is used for controlling the client to skip from the first payment interface to a second payment interface according to the client type, wherein the second payment interface is a payment interface of different client types corresponding to the target payment mode.

A third aspect of an embodiment of the present application provides an aggregated payment platform, including: a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the interface control method according to the first aspect when executing the computer program.

A fourth aspect of embodiments of the present application provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the computer program implements the interface control method according to the first aspect.

A fifth aspect of embodiments of the present application provides a computer program product, which when running on an aggregation payment platform, causes the aggregation payment platform to execute the interface control method according to the first aspect.

Compared with the prior art, the embodiment of the application has the advantages that: when receiving a product payment request sent by a client, the embodiment of the application firstly determines a target payment mode of the client based on the product payment request, secondly, based on the target payment mode of the client, the client is controlled to jump from the current interface to a first payment interface, the first payment interface is a webpage payment interface corresponding to the target payment mode, namely, aggregating the webpage payment interface of the payment platform, finally obtaining the client type of the client, according to the type of the client, the client is controlled to jump from the first payment interface to the second payment interface corresponding to the type of the client, the embodiment of the application can provide different payment interfaces according to the target payment mode of the client and the type of the client, by aggregating multiple payment schemes (i.e., multiple combinations of target payment methods and payment interfaces), a payment method and a payment interface with better payment experience can be selected for different clients.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

Fig. 1 is a schematic flowchart of an interface control method according to an embodiment of the present application;

FIG. 2 is a schematic flow chart illustrating control of current interface skip in the embodiment of the present application;

FIG. 3 is a schematic flow chart illustrating control of a first payment interface jump in an embodiment of the present application;

fig. 4 is a schematic flowchart of an interface control method according to a second embodiment of the present application;

fig. 5 is a schematic structural diagram of an interface control device according to a third embodiment of the present application;

fig. 6 is a schematic structural diagram of an aggregation payment platform provided in the fourth embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to" determining "or" in response to detecting ". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

It should be understood that, the sequence numbers of the steps in this embodiment do not mean the execution sequence, and the execution sequence of each process should be determined by the function and the inherent logic of the process, and should not constitute any limitation to the implementation process of the embodiment of the present application.

The research of the prior art shows that multiple combination modes exist between the payment channel and the payment interface (for example, payment is performed by using software with a payment function on a computer website, or payment is performed by using software with a payment function on mobile phone software, etc.), the realization of the complex combination modes requires that merchants negotiate prices with manufacturers of the payment channels one by one, different interfaces are connected and different payment interfaces are displayed for different clients, and the development cost and the later maintenance cost are higher. Therefore, the prior art provides an aggregated payment method, which can integrate a plurality of payment channels through a uniform cash desk, a merchant does not need to negotiate price with a manufacturer of each payment channel one by one, and can directly call the corresponding payment channel through an aggregated payment platform, but because different customer interfaces have different access modes, such as an android interface, an IOS interface or a web interface, for the three interfaces, the aggregated payment platform generally provides three different access modes, and a merchant end needs to correspondingly develop an interface of a payment interface three times, so that the development workload is large.

Based on the above, the application provides an interface control method, which can determine a target payment mode of a client by receiving a product payment request of the client, then control the client to jump from a current interface to a first payment interface based on the target payment mode of the client, wherein the first payment interface is a webpage payment interface corresponding to the target payment mode, namely, a webpage payment interface of an aggregation payment platform, finally obtain the client type of the client, and control the client to jump from the first payment interface to a second payment interface corresponding to the client type according to the client type, the aggregation payment platform of the embodiment of the application can provide different payment interfaces according to the target payment mode and the client type of the client, so as to select the payment mode and the payment interface with the best payment experience on different clients, thereby enhancing user experience, the aggregated payment platform aggregates the interfaces of the payment interfaces corresponding to different client types respectively, so that the corresponding interfaces of the payment interfaces can be directly called when different payment interfaces are rendered according to different client types, a merchant does not need to develop the corresponding interfaces of the payment interfaces according to the access modes of different clients, and the development workload of the merchant is reduced.

In order to explain the technical solution of the present application, the following description is given by way of specific examples.

Referring to fig. 1, a flowchart of an interface control method provided in an embodiment of the present application is shown. As shown in fig. 1, the interface control method may include the steps of:

step 101, if a product payment request sent by a client is received, determining a target payment mode of the client based on the product payment request.

In the embodiment of the present application, the product payment request may include product information, product amount, client type of the client, IP attribution of the client, payment channel preference, and the like. The product information may include a name and a type of the product, the type of the product may include a disposable product, a monthly rental product (such as a member recharging product), a large-amount installment product (i.e., a product whose product amount exceeds a preset amount and which can be installment-divided), and a non-mortgage product (i.e., a product without a collateral deposit), the type of the client may include an Application (APP), a computer website, a mobile web page, an applet, a public number, and the like, an IP attribution of the client may refer to any country in the world, a payment channel privilege may refer to a privilege corresponding to any payment channel, and the privilege may include a coupon, a full reduction, a cash-back, and the like.

In the embodiment of the application, the target payment mode of the client can be determined based on the product information, the product amount, the client type of the client, the IP attribution of the client and the payment preferential channel sent by the client.

In one possible embodiment, determining the target payment method of the client based on the product payment request comprises:

determining at least one candidate payment means based on the product payment request;

and sending the at least one candidate payment mode to the client.

In the embodiment of the application, the at least one candidate payment method is used for instructing the client to determine the target payment method based on the at least one candidate payment method and feed back the target payment method.

Exemplarily, when the aggregate payment platform receives a product payment request sent by a client, an interface of at least one payment channel can be called according to the product payment request, that is, at least one candidate payment method is determined, the at least one candidate payment method is sent to the client, so that the at least one candidate payment method is displayed on a current interface of the client, when the client touches any one of the candidate payment methods displayed on the client, the client can detect a touch action and obtain a touch position corresponding to the touch action so as to determine the candidate payment method at the touch position, and after the candidate payment method at the touch position is determined, the candidate payment method is sent to the aggregate payment platform, and the aggregate payment platform can determine that the candidate payment method is a target payment method; or when only one candidate payment mode is available, the candidate payment mode can be directly determined as the target payment mode without receiving the candidate payment mode sent by the client, so that the running speed of the terminal equipment is increased.

In one possible embodiment, determining at least one candidate payment method based on the product payment request includes:

determining N payment decision factors contained in the product payment request based on the product payment request, wherein N is an integer larger than zero;

and determining at least one candidate payment mode according to the payment decision rule corresponding to each of the N payment decision factors.

In the embodiment of the application, the product type, the client type of the client, the IP attribution of the client, the product amount and the payment channel privilege included in the product payment request can be used as payment decision factors, and each payment decision factor has a payment decision rule corresponding to each payment decision factor.

The payment decision rule corresponding to the product type may refer to: if the product type is a monthly rental product, determining that the candidate payment mode comprises an automatic renewal option; and if the product type is a large-amount installment product, determining that the candidate payment mode comprises installment payment options. The payment decision rule corresponding to the client type of the client may refer to: determining the candidate payment method includes a payment option corresponding to the client type. The payment decision rule corresponding to the IP home of the client may refer to: and determining candidate payment modes comprising the payment modes in the area of the IP home location of the client. The payment decision rule corresponding to the product amount may refer to: if the product amount is larger than or equal to the preset amount, determining that the candidate payment mode comprises an installment payment option; and if the product amount is less than the preset amount, determining that the candidate payment mode comprises a full payment option. The payment decision rule corresponding to the payment channel preference may refer to: and determining the candidate payment mode to comprise payment options corresponding to the payment channel preference.

For example, assuming that a U.S. customer purchases a mobile phone at an APP, the amount of the mobile phone is $ 1099, and the reduction rate is 10% for a period of 6 or more, according to the payment decision rule, first, a payment decision factor including a product type of a large-amount periodic product, a client type of the client is APP, an IP attribution of the client is the united states, the amount of the product is $ 1099, and a payment channel preference is the reduction rate may be obtained, and based on the payment decision factor, according to a corresponding payment decision rule, the determined candidate payment options may include: 1. the Klarna credit card pays by stages, and the payment can be reduced by 10 percent when the payment is carried out for more than 6 stages, and the payment is carried out in APP; 2. paypal pay once, pay within APP.

In one possible implementation, the optimal payment method in the candidate payment methods may be determined by setting the priority of the payment decision rule, and the optimal payment method is arranged in the first place in the queue of all candidate payment methods.

In the embodiment of the application, all the candidate payment modes are at least two. Wherein, the priority of the payment decision rule can be set as: the payment channel privilege > product amount > IP attribution of the client > product type > client type, and according to the setting of the priority, the optimal payment mode can be determined to be the payment mode with the maximum payment privilege. The priority of the payment decision rule may also be set as: the IP attribution of the client side > the payment channel preference > the product amount > the client side type of the client side > the product type, according to the setting of the priority, the optimal payment mode can be determined to be the payment mode in the area where the IP attribution of the client side is located, if the number of the payment modes in the area where the IP attribution of the client side is located is multiple, the multiple payment modes in the area where the IP attribution of the client side is located can be sorted based on the number of the users, and the number of the users used is the largest and is ranked in the first place.

It should be understood that the candidate payment means refers to the payment means provided by the aggregated payment platform to the client that can be selected by the client.

In one possible embodiment, determining the target payment method of the client based on the product payment request further comprises:

determining an optimal payment mode according to the N payment decision factors in the product payment request, the payment decision rules corresponding to the N payment decision factors and the priority of each payment decision rule;

and determining that the optimal payment mode is a target payment mode of the client, wherein the target payment mode is used for indicating the aggregation payment platform to control the client to jump from the current interface to the first payment interface.

The method comprises the steps that a payment decision factor corresponding to a payment decision rule with the highest priority is determined, the determined payment mode is an optimal payment mode, the optimal payment mode can be automatically determined to be a target payment mode, the aggregation payment platform can automatically control a client to jump from a current interface to a first payment interface according to the target payment mode, in the process, the aggregation payment platform automatically determines the target payment mode without active selection of a client, interaction between the client and the aggregation payment platform can be reduced, and the technological sense is further enhanced.

Exemplarily, assuming that a U.S. customer purchases a mobile phone on a certain APP, the amount of the mobile phone is $ 1099, and the payment decision rule corresponding to the preferential payment channel can be reduced by 10% in the period of 6, and the payment decision rule with the highest priority is the payment decision rule corresponding to the preferential payment channel, the payment mode with the highest preferential level is the optimal payment mode, so that the optimal payment mode can be determined to be the payment of the klana credit card in the period of 6, the optimal payment mode is determined to be the target payment mode, the aggregation payment platform can automatically control the client to jump to the first payment interface corresponding to the periodical payment of the klana credit card from the current interface, and the user does not need to select.

In a possible implementation manner, before receiving the product request sent by the client, the method further includes:

acquiring product order information sent by a merchant terminal, and generating a corresponding product payment order based on the product order information;

the product payment order is sent to the client.

In the embodiment of the application, the product order information is order information generated by a merchant based on a product selected by a customer, and the product payment order is used for instructing a client to generate a product payment request based on the product payment order and feeding back the product payment request.

The interaction among the aggregated payment platform, the merchant terminal and the client is as follows: the method comprises the steps that firstly, a client side selects products to purchase, selects the products to place orders, sends order placing requests of the products to a merchant side, the merchant side generates product order information of the products based on the order placing requests and sends the product order information to an aggregation payment platform, the aggregation payment platform generates corresponding product payment orders based on the product order information and sends the product payment orders to the client side, at the moment, the client side interface displays a product payment interface after the order placing of the products is successful, when the client side clicks a payment button on the client side interface, the client side receives payment instructions of the client side, generates product payment requests according to the payment instructions, and sends the product payment requests to the aggregation payment platform.

And 102, controlling the client to jump to the first payment interface from the current interface based on the target payment mode.

In this embodiment of the application, the first payment interface refers to a web page payment interface corresponding to the target payment method, that is, a payment interface corresponding to the target payment method is displayed in a web page, where the web page payment interface may be a mobile web page payment interface (for example, a mobile phone web page payment interface) or a computer web page payment interface. The control of the client to jump from the current interface to the first payment interface may refer to the control of the client to jump from the current interface to a payment interface, which is a webpage and corresponds to the target payment mode, and has a payment environment.

Illustratively, the payment environment is a Web page and the payment interface corresponding to the target payment means may refer to a payment interface in a form of World Wide Web (Web) corresponding to the target payment means, wherein the Web form is one of the Web page representations.

In one possible embodiment, controlling the client to jump from the current interface to the first payment interface based on the target payment method includes:

generating a payment skip link based on the target payment mode;

and calling a target payment channel corresponding to the target payment mode based on the payment skip link so as to control the client to skip from the current interface to the first payment interface.

In the embodiment of the application, the target payment mode is selected by the client based on at least one candidate payment mode, the aggregation payment platform generates a payment jump link based on the target payment mode sent by the client, calls an interface of a target payment channel corresponding to the target payment mode based on the payment jump link, and controls the client to jump from a current interface to a first payment interface by executing a program code corresponding to the interface.

Exemplarily, as shown in fig. 2, a schematic flow chart for controlling the current interface skip is shown, for example, the candidate payment mode includes any one of the payment modes existing in the prior art, such as a WeChat payment mode, a Paibao payment mode, a UnionPay payment mode, a Paypal payment mode, a Stripe payment mode, and the like, the determined target payment mode is a WeChat payment mode, a payment skip link is generated, a WeChat payment channel interface corresponding to the WeChat payment is called, a program code corresponding to the WeChat payment channel interface is executed, and the client is controlled to skip from the current interface to the WeChat payment interface in a payment environment under a webpage.

It should be understood that if the target payment mode is determined to be paypal payment, a payment skip link is generated, a paypal payment channel interface corresponding to paypal payment is called, a program code corresponding to the paypal payment channel interface is executed, and the client is controlled to skip from the current interface to a paypal payment WeChat payment interface with a payment environment under a webpage.

It should also be understood that, based on any target payment method, the method for controlling the client to jump from the current interface to the first payment interface is the same as the above-mentioned method for controlling the client to jump from the current interface to the first payment interface based on the WeChat payment and the paypal payment, and may refer to each other, which is not described herein again in this embodiment of the present application.

And 103, acquiring the client type of the client.

In the embodiment of the application, the client type of the client can be obtained from a product payment request sent by the client, and the product payment request comprises the client type of the client. The client type may include APP, computer website, mobile web page, applet, public number, and the like.

And 104, controlling the client to jump from the first payment interface to the second payment interface according to the type of the client.

In this embodiment of the application, the second payment interface refers to a payment interface of different client types corresponding to the target payment method. The control of the client to jump from the first payment interface to the second payment interface may refer to that the control of the client jumps from a webpage payment interface corresponding to the target payment mode to a payment interface corresponding to the target payment mode and matching with the client type, that is, jumps from the webpage payment interface to a payment interface matching with the client type, where the payment interface matching with the client type refers to that each client type has a payment interface matching with the client type, for example, if the client type is a computer website, the payment interface matching with the client type is a computer webpage payment interface; if the client type is APP, small programs, public numbers and the like installed on the mobile phone, the payment interface matched with the client type is a mobile phone client payment interface.

In one possible embodiment, controlling the client to jump from the first payment interface to the second payment interface according to the client type includes:

determining a target skipping mode for skipping to a second payment interface according to the type of the client, wherein the target skipping mode is a skipping mode corresponding to the type of the client;

calling a target interface corresponding to the target skipping mode according to the target skipping mode;

and executing the program code corresponding to the target interface to control the client to jump from the first payment interface to a second payment interface corresponding to the type of the client.

In the embodiment of the application, the target jump modes corresponding to different client types are different, for example, when the client type is an APP, the target jump mode is a jsbridge technology jump plus an APP payment environment jump; and when the client type is the public number, the target jump mode is the jsbridge technology jump.

It should be understood that different client types may correspond to the same payment interface or different payment interfaces for the same target payment method, for example, for a wechat payment method, when the client types are the same mobile phone client (for example, APP, mobile web page, applet, and public number on the mobile phone), the corresponding payment interface is a wechat client payment interface; when the client type is a computer website, the corresponding payment interface is a WeChat payment interface of a computer webpage (for example, a payment interface displaying a WeChat two-dimensional code).

The target jump method is different, so called target interfaces are also different, after the target jump method is determined, a target interface corresponding to the jump method is called, for example, when the target payment method is WeChat payment and the client type is APP, a first target interface corresponding to a jsbridge technology and a second target interface jumped to an APP payment environment are called, the first target interface corresponding to the jsbridge technology is called, a program code corresponding to the first target interface is executed, a WeChat native Software Development Kit (SDK) in the APP is pulled up, when the second target interface jumped by the APP payment environment is detected to exist (namely, the existence of a WeChat client is explained), the corresponding program code of the second target interface is executed, and the client displays the payment interface of the WeChat client.

Exemplarily, as shown in fig. 3, which is a schematic flow diagram for controlling the jump of the first payment interface, the target payment method received by the available aggregated payment platform according to fig. 3 is a WeChat payment method, the client is APP, after receiving the target payment mode and the client type, opening a webpage payment interface (i.e. a first payment interface) of the aggregated payment platform through the web, and since the received client type is APP, determining the payment environment corresponding to the target payment mode as APP, firstly pulling up a WeChat native Software Development Kit (SDK) in the APP through a first target interface corresponding to the jsbridge technology, displaying a WeChat payment interface in the APP, when detecting that a second target interface for jumping the APP payment environment exists, the corresponding program code of the second target interface is executed and the client displays the payment interface of the wechat client.

If the received client type is a mobile webpage, a public number and an applet, determining that the corresponding payment environment is the mobile webpage, the public number and the applet respectively, determining that the target jump mode is a jsbridge technology jump, calling a target interface which corresponds to the jsbridge technology and is matched with the client type, executing a program code at the target interface, and controlling the client to jump from a webpage WeChat payment interface of the aggregation payment platform to a payment interface of the WeChat client.

If the received client type is a computer website, the payment environment is determined to be the computer website, the target skipping mode is determined to be local payment environment skipping, a target interface corresponding to the local payment environment skipping needs to be called, program codes at the target interface are executed, and the payment interface of the WeChat two-dimensional code is displayed.

It should be understood that the dotted line in fig. 3 indicates that the confirmed payment environment is any one of a computer website, a mobile web page, an APP, an applet, and a public number, and it is not understood that five payment environments exist in parallel.

It should also be understood that the target payment method received by the aggregated payment platform may be any one of candidate payment methods (for example, precious payment, unionpay, paypal payment, Stripe payment, etc.), and when the target payment method received by the aggregated payment platform is any one of the candidate payment methods, a method for controlling the client to jump from the first payment interface to the second payment interface is the same as a method for controlling the client to jump from the first payment interface to the second payment interface when the target payment method is WeChat payment, which may be referred to each other, and this application embodiment is not described herein again. In the embodiment of the application, when a product payment request sent by a client is received, the embodiment of the application firstly determines a target payment mode of the client based on the product payment request, secondly, based on the target payment mode of the client, the client is controlled to jump from the current interface to a first payment interface, the first payment interface is a webpage payment interface corresponding to the target payment mode, namely, aggregating the webpage payment interface of the payment platform, finally obtaining the client type of the client, according to the type of the client, the client is controlled to jump from the first payment interface to the second payment interface corresponding to the type of the client, the embodiment of the application can provide different payment interfaces according to the target payment mode of the client and the type of the client, by aggregating multiple payment schemes (i.e., multiple combinations of target payment methods and payment interfaces), a payment method and a payment interface with better payment experience can be selected for different clients.

Referring to fig. 4, a flowchart of an interface control method provided in the second embodiment of the present application is shown. As shown in fig. 4, the interface control method may include the steps of:

step 401, if a product payment request sent by a client is received, determining a target payment mode of the client based on the product payment request.

And step 402, controlling the client to jump to the first payment interface from the current interface based on the target payment mode.

Step 403, obtaining the client type of the client.

And step 404, controlling the client to jump from the first payment interface to the second payment interface according to the client type.

The steps 101-104 of this embodiment are the same as the steps 401-404 of the previous embodiment, which can be referred to mutually, and the description of this embodiment is not repeated herein.

And step 405, if a payment result of the client on the second payment interface is received, sending the payment result to the merchant terminal.

In the embodiment of the application, when the customer completes payment in the second payment interface, the payment result is sent to the payment channel corresponding to the target payment mode, the payment channel can send the payment result to the aggregated payment platform through the interface connected with the aggregated payment platform, and the payment result can be sent to the merchant end after the payment result is received, so that the merchant end can obtain the payment result of the customer for the product.

Step 406, if a payment inquiry command sent by the merchant terminal is received, inquiring the payment state of the product payment order corresponding to the payment inquiry command according to the payment inquiry command.

In the embodiment of the application, if the merchant terminal does not receive the payment result of the product within the preset time after sending the product order information to the aggregation payment platform, the inquiry payment instruction is actively sent to the aggregation payment platform, and if the aggregation payment platform receives the inquiry payment instruction sent by the merchant terminal, the merchant terminal can be proved not to receive the payment result of the product, and then the payment state of the product payment order corresponding to the payment inquiry instruction is inquired according to the inquiry payment instruction, wherein the inquiry action is mainly aimed at timely synchronizing the payment state of the product order when the interface connected with the payment channel and the aggregation payment platform delays or fails in the data transmission process.

In a possible implementation, the interface control method further includes:

and if the fact that the number of times that the client sends the product payment request for the same product in the same time period is larger than the number threshold value is detected, sending an alarm prompt to the client.

In the embodiment of the application, the same time period refers to that the product payment requests sent for the same product are located in the same time period, and the number of times that the product payment requests are sent for the same product in the same time period is greater than the number threshold, which indicates that a problem that a client may have repeated payment for the same product, at this time, an alarm prompt needs to be sent to the client to avoid the client from performing repeated payment for the same product.

Compared with the first embodiment, in the embodiment of the application, the aggregated payment platform and the merchant terminal perform communication of the payment result for the transacted product, and in order to ensure that the payment state of the product order can be synchronized in time, the payment state of the product payment order corresponding to the payment inquiry instruction is inquired by receiving the payment inquiry instruction sent by the merchant terminal, so that the merchant terminal can obtain the payment result in time.

Referring to fig. 5, a schematic structural diagram of an interface control device provided in the third embodiment of the present application is shown, and for convenience of description, only the portions related to the third embodiment of the present application are shown.

The interface control device 5 may specifically include the following modules:

a payment determining module 501, configured to determine, based on a product payment request sent by a client, a target payment method of the client if the product payment request is received;

a first skip control module 502, configured to control, based on a target payment mode, a client to skip from a current interface to a first payment interface, where the first payment interface is a web payment interface corresponding to the target payment mode;

an obtaining module 503, configured to obtain a client type of the client;

and a second skip control module 504, configured to control, according to the client type, the client to skip from the first payment interface to a second payment interface, where the second payment interface is a payment interface of a different client type corresponding to the target payment mode.

In this embodiment, the interface control device 5 may further include the following modules:

the payment order generating module is used for acquiring product order information sent by the merchant terminal and generating a corresponding product payment order based on the product order information, wherein the product order information is order information generated by the merchant terminal based on products selected by the customer;

and the payment order sending module is used for sending the product payment order to the client, and the product payment order is used for indicating the client to generate a product payment request based on the product payment order and feeding back the product payment request.

In this embodiment of the present application, the payment determining module 501 may specifically include the following sub-modules:

the candidate determining submodule is used for determining at least one candidate payment mode based on the product payment request;

and the candidate sending submodule is used for sending the at least one candidate payment mode to the client, and the at least one candidate payment mode is used for indicating the client to determine a target payment mode based on the at least one candidate payment mode and feeding back the target payment mode.

In this embodiment of the present application, the candidate determining sub-module may specifically include the following units:

the factor determination unit is used for determining N payment decision factors contained in the product payment request based on the product payment request, wherein N is an integer larger than zero;

and the candidate determining unit is used for determining at least one candidate payment mode according to the payment decision rule corresponding to each of the N payment decision factors.

In this embodiment of the present application, the first skip control module 502 may specifically include the following sub-modules:

the link generation submodule is used for generating a payment skip link based on a target payment mode;

and the first skip submodule is used for calling a target payment channel corresponding to the target payment mode based on the payment skip link so as to control the client to skip from the current interface to the first payment interface.

In this embodiment of the present application, the second skip control module 504 may specifically include the following sub-modules:

the skip mode determining submodule is used for determining a target skip mode for skipping the second payment interface according to the type of the client, wherein the target skip mode is a skip mode corresponding to the type of the client;

the interface calling submodule is used for calling a target interface corresponding to the target skipping mode according to the target skipping mode;

and the second skip submodule is used for executing the program code corresponding to the target interface so as to control the client to skip from the first payment interface to a second payment interface corresponding to the type of the client.

the sending module is used for sending the payment result to the merchant terminal if the payment result of the client terminal on the second payment interface is received;

and the query module is used for querying the payment state of the product payment order corresponding to the payment query instruction according to the payment query instruction if the payment query instruction sent by the merchant terminal is received.

The interface device provided in the embodiment of the present application can be applied to the foregoing method embodiments, and for details, reference is made to the description of the foregoing method embodiments, which is not described herein again.

Fig. 6 is a schematic structural diagram of an aggregation payment platform provided in the fourth embodiment of the present application. As shown in fig. 6, the aggregated payment platform 600 of this embodiment includes: at least one processor 610 (only one shown in fig. 6), a memory 620, and a computer program 621 stored in the memory 620 and operable on the at least one processor 610, wherein the steps in any of the above-described interface control method embodiments are implemented when the computer program 621 is executed by the processor 610.

The aggregated payment platform 600 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The aggregated payment platform may include, but is not limited to, a processor 610, a memory 620. Those skilled in the art will appreciate that fig. 6 is merely an example of an aggregated payment platform 600 and does not constitute a limitation of aggregated payment platform 600, and may include more or fewer components than shown, or some components in combination, or different components, such as input output devices, network access devices, etc.

The Processor 610 may be a Central Processing Unit (CPU), and the Processor 610 may be other general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 620 may be, in some embodiments, an internal storage unit of the aggregated payment platform 600, such as a hard disk or a memory of the aggregated payment platform 600. The memory 620 may also be an external storage device of the aggregated payment platform 600 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, provided on the aggregated payment platform 600. Further, the memory 620 may also include both an internal storage unit and an external storage device of the aggregated payment platform 600. The memory 620 is used for storing an operating system, an application program, a Boot Loader (Boot Loader), data, and other programs, such as program codes of the computer programs. The memory 620 may also be used to temporarily store data that has been output or is to be output.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/aggregate payment platform and method may be implemented in other ways. For example, the above-described embodiments of the device/aggregate payment platform are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow in the method of the embodiments described above can be realized by a computer program, which can be stored in a computer-readable storage medium and can realize the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.

The present application may also implement all or part of the processes in the method of the above embodiments, and may also be implemented by a computer program product, when the computer program product runs on an aggregation payment platform, the steps in the above method embodiments may be implemented when the aggregation payment platform is executed.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same. Although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. An interface control method is applied to a convergence payment platform, and comprises the following steps:

acquiring the client type of the client;

2. The interface control method of claim 1, further comprising, prior to receiving the product payment request sent by the client:

acquiring product order information sent by a merchant terminal, and generating a corresponding product payment order based on the product order information, wherein the product order information is order information generated by the merchant terminal based on a product selected by a customer;

and sending the product payment order to the client, wherein the product payment order is used for instructing the client to generate a product payment request based on the product payment order and feeding back the product payment request.

3. The interface control method of claim 1, wherein determining the target payment method for the client based on the product payment request comprises:

and sending the at least one candidate payment mode to the client, wherein the at least one candidate payment mode is used for indicating the client to determine the target payment mode based on the at least one candidate payment mode and feeding back the target payment mode.

4. The interface control method of claim 3, wherein determining at least one candidate payment method based on the product payment request comprises:

determining N payment decision factors contained in the product payment request based on the product payment request, wherein N is an integer greater than zero;

and determining the at least one candidate payment mode according to the payment decision rule corresponding to each of the N payment decision factors.

5. The interface control method of claim 1, wherein the controlling the client to jump from the current interface to the first payment interface based on the target payment method comprises:

generating a payment skip link based on the target payment mode;

6. The interface control method of claim 1, wherein said controlling the client to jump from the first payment interface to a second payment interface based on the client type comprises:

determining a target skipping mode for skipping to a second payment interface according to the client type, wherein the target skipping mode is a skipping mode corresponding to the client type;

and executing a program code corresponding to the target interface to control the client to jump from the first payment interface to a second payment interface matched with the type of the client.

7. The interface control method of any one of claims 1-6, wherein the controlling the client to jump from the first payment interface to a second payment interface, further comprises:

if the payment result of the client on the second payment interface is received, the payment result is sent to a merchant terminal;

and if a payment inquiry instruction sent by the merchant terminal is received, inquiring the payment state of the product payment order corresponding to the payment inquiry instruction according to the payment inquiry instruction.

8. An interface control apparatus, characterized in that the interface control apparatus comprises:

the acquisition module is used for acquiring the client type of the client;

9. An aggregated payment platform comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor when executing the computer program implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 7.