CN115516482A - Aggregated payment method and related product - Google Patents
Aggregated payment method and related product Download PDFInfo
- Publication number
- CN115516482A CN115516482A CN202080100567.XA CN202080100567A CN115516482A CN 115516482 A CN115516482 A CN 115516482A CN 202080100567 A CN202080100567 A CN 202080100567A CN 115516482 A CN115516482 A CN 115516482A
- Authority
- CN
- China
- Prior art keywords
- payment
- target
- authorization
- mode
- target payment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
Abstract
An aggregated payment method and related products, the aggregated payment method comprising: receiving a payment request sent by a service system, wherein the payment request carries order information (301); determining a target payment mechanism (302) according to the order information; and selecting a target payment authorization mode corresponding to the target payment mechanism to apply payment authorization to the target payment mechanism (303), and calling the target payment mechanism to pay for the payment request (304). The convenience of payment can be improved.
Description
The application relates to the technical field of payment, in particular to an aggregated payment method and a related product.
Electronic payment has a very high popularity in China, and has become an indispensable mode in daily life. At present, dozens of payment mechanisms are available in the market, including third-party payment mechanisms and various banks, each payment mechanism has an application (App) of the payment mechanism, the payment process is complicated, and the payment convenience is low.
Disclosure of Invention
The embodiment of the application provides an aggregation payment method and a related product, and the convenience of payment can be improved.
A first aspect of an embodiment of the present application provides an aggregated payment method, including:
receiving a payment request sent by a service system, wherein the payment request carries order information;
determining a target payment mechanism according to the order information;
and selecting a target payment authorization mode corresponding to the target payment mechanism to apply payment authorization to the target payment mechanism, and calling the payment of the target payment mechanism aiming at the payment request.
A second aspect of an embodiment of the present application provides an aggregated payment device, including:
the first receiving unit is used for receiving a payment request sent by a service system, wherein the payment request carries order information;
the determining unit is used for determining a target payment mechanism according to the order information;
the payment authorization unit is used for selecting a target payment authorization mode corresponding to the target payment mechanism to apply for payment authorization to the target payment mechanism;
and the payment unit is used for calling the payment of the target payment mechanism aiming at the payment request.
A third aspect of an embodiment of the present application provides a terminal device, including a processor and a memory, where the memory is used to store a computer program, and the computer program includes program instructions, and the processor is configured to call the program instructions to execute the step instructions in the first aspect of the embodiment of the present application.
A fourth aspect of embodiments of the present application provides a computer-readable storage medium, where the computer-readable storage medium stores a computer program for electronic data exchange, where the computer program makes a computer perform part or all of the steps as described in the first aspect of embodiments of the present application.
A fifth aspect of embodiments of the present application provides a computer program product, wherein the computer program product comprises a non-transitory computer readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps as described in the first aspect of embodiments of the present application. The computer program product may be a software installation package.
In the embodiment of the application, an aggregation payment device receives a payment request sent by a service system, wherein the payment request carries order information; determining a target payment mechanism according to the order information; and selecting a target payment authorization mode corresponding to the target payment mechanism to apply payment authorization to the target payment mechanism, and calling the target payment mechanism to pay the payment request. In the embodiment of the application, the aggregation payment device can be connected with the service system and the payment mechanism in an abutting mode, the service system does not need to be directly connected with the payment mechanism in an abutting mode, the workload of accessing and paying the service system is saved, and the time of accessing and paying the service system is saved. Through the mode of aggregated payment, the influence of the difference between different payment mechanisms on the user is weakened or eliminated, the requirement that the service system adopts multiple modes to carry out payment is met, the payment flow of the user can be shortened, and the payment convenience is improved.
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a schematic structural diagram of an aggregation payment system provided in an embodiment of the present application;
fig. 2 is a schematic flow chart of an aggregate payment method provided in an embodiment of the present application;
fig. 3 is a schematic flow chart of another aggregate payment method provided in an embodiment of the present application;
FIG. 4 is a usage scenario diagram of an aggregate payment provided by an embodiment of the present application;
fig. 5 is a schematic structural diagram of an aggregation payment device according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a terminal device according to an embodiment of the present application.
The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some embodiments of the present application, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The terms "first," "second," and the like in the description and claims of the present application and in the foregoing drawings are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.
Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.
The terminal devices involved in the embodiments of the present application may include various handheld devices, vehicle-mounted devices, wearable devices, computing devices or other processing devices connected to a wireless modem, which have wireless communication functions, and various forms of User Equipment (UE), mobile Stations (MS), terminal devices (terminal device), and so on. For convenience of description, the above-mentioned devices are collectively referred to as terminal devices.
Referring to fig. 1, fig. 1 is a schematic structural diagram of an aggregation payment system provided in an embodiment of the present application, including a service system, an aggregation payment device, and a payment mechanism, where the service system includes a service system front end and a service system background, and the aggregation payment device includes an aggregation payment front end and an aggregation payment background. When a user orders goods at the front end of the business system, the back end of the business system receives the information of the ordered goods. The first step is as follows: a user initiates payment at the front end of a service system, and an aggregate payment front end displays an aggregate payment page; the second step is that: the user selects a desired payment mode on the aggregate payment page and initiates payment at the aggregate payment front end; the third step: after the user confirms the payment mode, the aggregation payment background can reach the corresponding payment mechanism to apply for authorization for the user, and the user can confirm payment in the payment mechanism through the authorization information of the payment mechanism; the fourth step: after the payment mechanism confirms the order receiving result, the payment mechanism informs the user of the background payment of aggregation in a background informing mode; the fifth step: and the aggregated payment sends the payment result of the user to the background of the service system in a background notification mode.
The service system front end can be carried in the terminal device, and the aggregation payment front end can also be carried in the terminal device. The service system background can be borne in the service system server, and the aggregate payment background can be borne in the aggregate payment server. The payment mechanism is a third party payment mechanism (such as WeChat and Payment treasures) holding the license plate for payment or a mechanism (such as a bank) with the qualification of acquiring the bill.
Aggregated payment is a system or product that organizes multiple payment methods in a consistent flow and operation to provide payment services to users.
The aggregation payment system in the embodiment of the application provides an integrated unified access platform with multiple payment modes for the service system, the difference among different payment mechanisms is hidden, and the workload of the service system for access payment is saved. The aggregate payment system does not deposit funds, and the funds are kept by payment institutions with bill receiving qualifications, so that the universality of the embodiment of the application is improved. Since the service system is different from the user system of the payment mechanism, and the user identifier is also different, the user identifier is not an essential item in the embodiment of the application, so that the dependence on the user can be reduced. The embodiment of the application uses the background notification as the only condition for successful payment, so that the background notification is isolated from the channel of the user in the payment process, and the uncertain state of the payment result and the attack to the payment result are avoided.
Referring to fig. 2, fig. 2 is a schematic flow chart of an aggregate payment method according to an embodiment of the present application. As shown in fig. 2, the aggregate payment method may include the following steps.
And 201, the aggregate payment device receives a payment request sent by the service system, wherein the payment request carries order information.
In the embodiment of the present application, users who aggregate payment may be divided into two types: one is an individual user, i.e. a customer of the business side system, who is the party who completes the payment in the payment activity. The other is the business party, also commonly referred to as the merchant. The payment request sent by the business system may be initiated by a customer of the business system or by a merchant.
The order information may reflect some information of the payment request sent by the service system, and the order information may include payment information, such as an order number of the service party, commodity information, payment amount, and the like.
The business order is an order generated by the business system ordering operation, and the order number of the business party is an order number generated by the business system and uniquely identifying the business order.
Optionally, the order information may further optionally include one or more of user information, payment key information, and control information.
The user information may include an identity token, a mobile phone number, and the like of the user; the payment key information can comprise a bank card number, a point card number or a password and the like; the control information may include a terminal type identifier, a service party identity identifier, a payment scenario, a payment method code, and the like.
The order information is information which is defined by the aggregate payment device and needs to be transmitted in, and can be transmitted in through a payment ordering interface.
Optionally, step 201 may include the following steps:
and the aggregation payment device receives a payment request sent by the service system, calls a payment ordering interface and transmits the order information into the payment ordering interface.
In the embodiment of the application, when different service systems send payment requests, order information needing to be transmitted may be different. For example, the order information entered by the business system supporting web page payment may include payment information and control information (e.g., web browser identification, business party identity identification). As another example, the order information transmitted by the business system for bank card or point card payment may include payment information and payment key information (e.g., a bank card number, a point card number or a password). For another example, some payment institutions require to acquire and transmit user information such as a one-time user token, and some payment institutions require to transmit user information such as a card number and a mobile phone number held by a user.
The aggregate payment device determines the target payment mechanism based on the order information 202.
In the embodiment of the application, the aggregation payment device can judge the payment scene according to the order information, determine the payment mechanism supported by the payment scene according to the payment scene, and the user can select the target payment mechanism from the payment mechanisms supported by the payment scene. The payment mechanisms supported by different payment scenarios may differ.
Typical payment scenarios may include the following:
(1) Mobile phone App payment scenario: an individual user holds the app designated by the payment mechanism, completes payment in the app of the payment mechanism, and is often used for mobile online payment. The payment mechanism supported by the payment scene is a payment mechanism corresponding to the payment mechanism app.
(2) Web pay (H5 pay) scenario: an individual user logs in a page designated by a payment mechanism through a webpage to complete payment on the page, which is commonly seen in PC (personal computer) terminal online payment. The payment mechanism supported by the payment scene is used for logging in the payment mechanism for an individual user through a webpage.
(3) Scanning a code payment scene: an individual user holds an app designated by a payment mechanism, scans a payment two-dimensional code generated by a service party to complete payment, and is usually used for cross-device payment (subscription occurs in a device A and payment is performed in a device B). The payment mechanism supported by the payment scene is a payment mechanism corresponding to the app specified by the payment mechanism for the human user.
(4) Card swiping payment scene: the individual user presents the issued bar code or two-dimensional code of the payment mechanism, and the business party reads the bar code by using the code scanning device to complete collection, which is common in offline scenes. The payment mechanism supported by the payment scenario is the payment mechanism presented by the individual user.
(5) A terminal-less payment scenario: an individual user does not need to use any terminal, for example, the individual user completes payment by swiping the face, which is common in offline payment scenarios. The payment mechanism supported by the payment scene is a payment mechanism supported by face brushing payment.
(6) Bank card or point card payment scenario: the individual user directly inputs the bank card or card number and necessary information in the ordering page of the business party to complete payment. The payment mechanism supported by the payment scene is a bank corresponding to the bank card.
Optionally, the order information includes control information, and the control information includes a terminal type identifier and a service party identity identifier; step 202 may include the steps of:
(11) The aggregation payment device determines a first payment mode set corresponding to the terminal type identifier, determines a second payment mode set corresponding to the service party identity identifier, and obtains an available payment mode set, wherein the available payment mode set comprises an intersection of the first payment mode set and the second payment mode set;
(12) The aggregate payment device displays an interface including the set of available payment methods;
(13) And the aggregation payment device receives a target payment mode selected by the user from the available payment mode set and determines a target payment mechanism corresponding to the target payment mode.
In the embodiment of the application, if the service system transmits the terminal type identifier and the service party identity identifier, the aggregation payment device can identify the terminal type according to the terminal type identifier. For example, it is identified whether a cell phone or other device initiating payment, on which is an App or browser, is in the business party App or the payment institution's App (such as a WeChat's public slave number page).
The business party identity identification may include a business party code. The available payment mode can be selected according to the terminal type identifier and the service party code. For example, the first payment method set correspondingly supported by the terminal type identifier includes a payment method 1, a payment method 2, a payment method 3, a payment method 4, and a payment method 5, the second payment method set correspondingly supported by the service party code includes a payment method 3, a payment method 5, and a payment method 6, and the available payment method set includes a payment method 3 and a payment method 5.
For example, a page opened in the App of the business party may support a large number of payment methods, but a page opened in the App of the payment mechanism generally only supports the payment method corresponding to the payment mechanism.
The payment modes in the available payment mode set can be filled into the message format which can be identified by the terminal, and the message format is displayed to the user for selection through the interface of the available payment mode set.
Optionally, after the user selects the target payment mode in the APP page, data in a specific format or a page may be returned. For example, data in a specific format (such as JSON) is returned for App, or a page is returned for a browser, and the format of the data returned for different terminal devices is different. The data that the user terminal type can identify the processing can be returned according to the terminal type.
Optionally, the order information includes control information, and the control information includes a payment method code; step 202 may include the steps of:
(21) The aggregation payment device determines a payment mode set corresponding to the payment mode code to obtain an available payment mode set;
(22) The aggregate payment device displays an interface including the set of available payment methods;
(23) And the aggregation payment device receives a target payment mode selected by the user from the available payment mode set and determines a target payment mechanism corresponding to the target payment mode.
In the embodiment of the application, if the service system transmits the payment mode codes of the payment modes supported by the service system, the set of all the payment modes corresponding to the payment mode codes can be used as the set of available payment modes and displayed for the user to select.
In the embodiment of the application, the aggregate payment mode can determine the supported available payment mode set according to the terminal type identifier and the service party identity identifier for the user to select, and determine the target payment mechanism corresponding to the target payment mode selected by the user, the service system does not need to be directly connected with the payment mechanism, the workload of the service system for accessing and paying is saved, and the time of the service system for accessing and paying is saved.
And 203, selecting a target payment authorization mode corresponding to the target payment mechanism by the aggregation payment device to apply payment authorization to the target payment mechanism.
In the embodiment of the application, different payment structures and different payment authorization modes are possible. For example, some payment institutions may only need to generate authorization locally, and some payment institutions may require a request to be sent to a backend server for authorization.
The aggregation payment device can select a target payment authorization mode corresponding to the target payment mechanism to apply payment authorization to the target payment mechanism according to the corresponding relation between the payment mechanism and the payment authorization mode. The method and the system can weaken or eliminate the influence on the user caused by the difference of payment authorization among different payment mechanisms, meet the requirement that a business system adopts multiple modes to carry out payment, shorten the payment flow of the user and improve the convenience of payment.
Optionally, step 203 may include the following steps:
(31) The aggregation payment device determines a target payment authorization mode corresponding to the target payment mechanism according to the corresponding relation between the payment mechanism and the payment authorization mode:
(32) And the aggregation payment device applies for payment authorization to the target payment mechanism according to the target payment authorization mode.
In the embodiment of the application, the payment authorization modes of different payment mechanisms may be different. For example, some payment authorities do not require payment authorization. Some payment institutions only need to generate authorization locally, and some require sending a request to a backend server for authorization. The payment authorization mode of each payment mechanism can be determined, and after the target payment mechanism is determined, the target payment authorization mode corresponding to the target payment mechanism can be determined according to the stored corresponding relation between the payment mechanism and the payment authorization mode. The aggregation payment mode can process payment authorization of various payment mechanisms, reduces workload of accessing a plurality of payment mechanisms, and saves time of accessing a service system for payment.
Optionally, in step (32), the step of applying payment authorization from the target payment authority to the target payment authority by the aggregation payment apparatus according to the target payment authorization manner may include the following steps:
and if the target payment authorization mode is a local authorization mode, the aggregation payment device generates a digital signature according to the order information.
In the embodiment of the application, if the target authorization payment mode is a local authorization mode, for example, the target authorization payment mode is payment for a payment instrument, the aggregation payment device generates a digital signature according to the order information. The local authorization mode does not need to carry out authorization on a server of the target payment mechanism, so that the payment authorization process can be shortened, and the payment authorization speed is increased. A digital signature is some data appended to a data unit or a cryptographic transformation performed on a data unit. Such data or transformations allow the recipient of the data unit to verify the source of the data unit and the integrity of the data unit and to protect the data against counterfeiting by a person (e.g., the recipient). For example, a digital signature may be appended to the order information.
Optionally, in step (32), the step of applying payment authorization from the target payment authority to the target payment authority by the aggregation payment apparatus according to the target payment authorization manner may include the following steps:
if the target payment authorization mode is a server authorization mode, the aggregate payment device calls a payment authorization interface provided by the target payment mechanism, transmits payment information required by the target payment mechanism to a server of the target payment mechanism, and applies for payment authorization to the server of the target payment mechanism.
In the embodiment of the application, if the target payment authorization mode is a server authorization mode, for example, the target authorization payment mode is WeChat payment, the aggregation payment device calls a payment authorization interface provided by a WeChat payment mechanism, transmits payment information required by the WeChat payment mechanism into a server of the WeChat payment mechanism, and applies for payment authorization to the server of the WeChat payment mechanism. The server authorization mode needs to be authorized at the server of the target payment mechanism, the server of the target payment mechanism can record the authorization information in time, and the security of payment authorization can be improved.
204, the aggregate payment device invokes the payment requested by the target payment authority for the payment.
In the embodiment of the application, after the payment authorization is completed, the aggregation payment device can complete the payment through the target payment mechanism according to the payment request of the target payment mechanism. The aggregation payment device does not perform specific payment actions, payment is completed through the target payment mechanism, the aggregation payment system does not deposit funds, and the funds are kept by the payment mechanism with the bill receiving qualification, so that the universality of the embodiment of the application is improved.
In the embodiment of the application, the aggregation payment device can be connected with the service system and the payment mechanism in an abutting mode, the service system does not need to be directly connected with the payment mechanism in an abutting mode, the workload of accessing and paying the service system is saved, and the time of accessing and paying the service system is saved. Through the mode of aggregate payment, the influence of the difference between different payment mechanisms on the user is weakened or eliminated, the demand that the business system adopts multiple modes to pay is met, the payment flow of the user can be shortened, and the payment convenience is improved.
Referring to fig. 3, fig. 3 is a schematic flowchart of another aggregate payment method according to an embodiment of the present application. As shown in fig. 3, the aggregate payment method may include the following steps.
301, the aggregate payment device receives a payment request sent by the service system, where the payment request carries order information.
And 302, the aggregate payment device determines a target payment mechanism according to the order information.
303, the aggregated payment device selects a target payment authorization mode corresponding to the target payment mechanism to apply for payment authorization to the target payment mechanism.
The aggregate payment device invokes the payment requested by the target payment authority for the payment 304.
The specific implementation of steps 301 to 304 in the embodiment of the present application may refer to steps 201 to 204 shown in fig. 1, which is not described herein again.
And 305, receiving a payment result notice sent by the target payment mechanism by the aggregation payment device, and sending the payment result notice to the service system, wherein the payment result notice comprises a service order number and a payment state.
In the embodiment of the application, after the target payment mechanism completes the payment operation, the target payment mechanism may send a payment result notification to the aggregated payment system, where the payment result notification may include a service order number and a payment status. The service order number is generated by the aggregate payment device according to the payment request, and the payment status may include payment success or payment failure. The payment result notification is a background notification mode.
The embodiment of the application uses a uniform payment result notification interface to inform the service side system of the payment result. The specific method comprises the following steps: payment result confirmation is completed by the aggregated payment device in a manner approved by the payment authority, and then a payment result confirmation notification is initiated. The embodiment of the application uses the background notification as the only condition for successful payment, so that the background notification is isolated from the channel of the user in the payment process, the uncertain state of the payment result and the attack to the payment result can be avoided, and the reliability and the safety of the payment are improved.
In the embodiment of the application, the aggregation payment device can be connected with the service system and the payment mechanism in an abutting mode, the service system does not need to be directly connected with the payment mechanism in an abutting mode, the workload of accessing and paying the service system is saved, and the time of accessing and paying the service system is saved. Through the mode of aggregate payment, the influence of the difference between different payment mechanisms on the user is weakened or eliminated, the demand that the business system adopts multiple modes to pay is met, the payment flow of the user can be shortened, and the payment convenience is improved. The background notification is used as the only condition for successful payment, so that the background notification is isolated from a channel of a user payment process, the uncertain state of a payment result and the attack to the payment result can be avoided, and the reliability and the safety of the payment are improved.
Referring to fig. 4, fig. 4 is a usage scenario diagram of aggregated payment according to an embodiment of the present application. The usage scenario is shown in fig. 4, and includes a business system order page, an aggregate payment presentation page, and a payment authority page. And the user finishes ordering on the ordering page of the business system, enters the aggregate payment display page during payment, and jumps to the app or page of the payment mechanism to pay by selecting a specific payment mode. The aggregated payment scene can meet the requirement of diversified payment means of a business system, shorten the payment path of a user and improve the payment conversion rate of the user.
The above description has introduced the solution of the embodiment of the present application mainly from the perspective of the method-side implementation process. It is understood that the terminal device includes hardware structures and/or software modules for performing the respective functions in order to implement the functions. Those of skill in the art will readily appreciate that the present application is capable of hardware or a combination of hardware and computer software implementing the various illustrative elements and algorithm steps described in connection with the embodiments provided herein. Whether a function is performed in hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. 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 embodiment of the present application, the terminal device may be divided into the functional units according to the above method example, for example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing 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. It should be noted that the division of the unit in the embodiment of the present application is schematic, and is only a logic function division, and there may be another division manner in actual implementation.
In accordance with the foregoing, referring to fig. 5, fig. 5 is a schematic structural diagram of an aggregation payment apparatus provided in an embodiment of the present application, where the aggregation payment apparatus 500 is applied to a terminal device, and the aggregation payment apparatus 500 may include a first receiving unit 501, a determining unit 502, a payment authorization unit 503, and a payment unit 504, where:
a first receiving unit 501, configured to receive a payment request sent by a service system, where the payment request carries order information;
a determining unit 502, configured to determine a target payment mechanism according to the order information;
a payment authorization unit 503, configured to select a target payment authorization manner corresponding to the target payment mechanism and apply for payment authorization to the target payment mechanism;
a payment unit 504, configured to invoke payment of the target payment authority for the payment request.
Optionally, the order information includes a terminal type identifier and a service party identity identifier; the determining unit 502 determines a target payment mechanism according to the order information, specifically: determining a first payment mode set corresponding to the terminal type identifier, determining a second payment mode set corresponding to the service party identity identifier, and obtaining an available payment mode set, wherein the available payment mode set comprises an intersection of the first payment mode set and the second payment mode set; displaying an interface containing the set of available payment methods; and receiving a target payment mode selected by a user from the available payment mode set, and determining a target payment mechanism corresponding to the target payment mode.
Optionally, the order information includes control information, and the control information includes a payment method code; the determining unit 502 determines a target payment mechanism according to the order information, specifically: determining a payment mode set corresponding to the payment mode code to obtain an available payment mode set; displaying an interface containing the set of available payment methods; and receiving a target payment mode selected by a user from the available payment mode set, and determining a target payment mechanism corresponding to the target payment mode.
Optionally, the payment authorization unit 503 selects a target payment authorization manner corresponding to the target payment mechanism to apply for payment authorization to the target payment mechanism, specifically: determining a target payment authorization mode corresponding to the target payment mechanism according to the corresponding relation between the payment mechanism and the payment authorization mode: and applying for payment authorization to the target payment mechanism according to the target payment authorization mode.
Optionally, the payment authorization unit 503 applies for payment authorization to the target payment mechanism according to the target payment authorization manner, specifically: and generating a digital signature according to the order information under the condition that the target payment authorization mode is a local authorization mode.
Optionally, the payment authorization unit 503 applies for payment authorization to the target payment mechanism according to the target payment authorization manner, specifically: and under the condition that the target payment authorization mode is a server authorization mode, calling a payment authorization interface provided by the target payment mechanism, transmitting payment information required by the target payment mechanism into a server of the target payment mechanism, and applying for payment authorization to the server of the target payment mechanism.
Optionally, the first receiving unit 501 receives a payment request sent by a service system, specifically: and receiving a payment request sent by a service system, calling a payment ordering interface, and transmitting the order information in the payment ordering interface.
The aggregate payment apparatus 500 may further include a second receiving unit 505 and a transmitting unit 506;
the second receiving unit 505 is configured to receive a payment result notification sent by the target payment mechanism;
the sending unit 506 is configured to send the payment result notification to the service system, where the payment result notification includes a service order number and a payment status.
The determining unit 502, the payment authorizing unit 503 and the payment unit 504 in this embodiment may be processors in a terminal device, and the first receiving unit 501, the second receiving unit 505 and the sending unit 506 may be communication interfaces in the terminal device.
Optionally, the aggregate payment apparatus 500 may further include a storage unit, where the storage unit is configured to store relevant information in the payment process, including a service order number, a payment order number, commodity information, a payment amount, a payment status, and the like. The storage unit 506 may be a memory (e.g., a nonvolatile memory) in the terminal device.
In the embodiment of the application, the aggregation payment device can be connected with the service system and the payment mechanism in an abutting mode, the service system does not need to be directly connected with the payment mechanism in an abutting mode, the workload of the service system for accessing and paying is saved, and the time of the service system for accessing and paying is saved. Through the mode of aggregate payment, the influence of the difference between different payment mechanisms on the user is weakened or eliminated, the demand that the business system adopts multiple modes to pay is met, the payment flow of the user can be shortened, and the payment convenience is improved.
Referring to fig. 6, fig. 6 is a schematic structural diagram of a terminal device according to an embodiment of the present disclosure, and as shown in fig. 6, the terminal device 600 includes a processor 601 and a memory 602, and the processor 601 and the memory 602 may be connected to each other through a communication bus 603. The communication bus 603 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus 603 may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 6, but this is not intended to represent only one bus or type of bus. The memory 602 is used for storing a computer program comprising program instructions, the processor 601 being configured for invoking the program instructions, the program comprising instructions for performing the methods shown in fig. 2 to 3.
The processor 601 may be a general purpose Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the above schemes.
The Memory 602 may be, but is not limited to, a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory may be self-contained and coupled to the processor via a bus. The memory may also be integrated with the processor.
In addition, the terminal device 600 may further include a communication interface 604, an antenna, and other common components, which are not described in detail herein.
In the embodiment of the application, the terminal equipment can be connected with the service system and the payment mechanism through the aggregation payment system, the service system does not need to be directly connected with the payment mechanism, the workload of the service system for accessing and paying is saved, and the time of the service system for accessing and paying is saved. Through the mode of aggregate payment, the influence of the difference between different payment mechanisms on the user is weakened or eliminated, the demand that the business system adopts multiple modes to pay is met, the payment flow of the user can be shortened, and the payment convenience is improved.
Embodiments of the present application also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, and the computer program enables a computer to execute part or all of the steps of any one of the aggregate payment methods as described in the above method embodiments.
Embodiments of the present application also provide a computer program product comprising a non-transitory computer readable storage medium storing a computer program, the computer program causing a computer to perform some or all of the steps of any of the aggregated payment methods as recited in the above method embodiments.
It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art will recognize that the embodiments described in this specification are preferred embodiments and that acts or modules referred to are not necessarily required for this application.
In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to the related descriptions of other embodiments.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implementing, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed coupling or direct coupling or communication connection between each other may be through some interfaces, indirect coupling or communication connection between devices or units, and may be in an electrical 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 position, or may be distributed on multiple 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 invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may be implemented in the form of a software program module.
The integrated unit, if implemented in the form of a software program module and sold or used as a stand-alone product, may be stored in a computer readable memory. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product stored in a memory, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned memory comprises: various media capable of storing program codes, such as a usb disk, a read-only memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and the like.
Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by associated hardware instructed by a program, which may be stored in a computer-readable memory, which may include: flash memory disks, read-only memory, random access memory, magnetic or optical disks, and the like.
The foregoing detailed description of the embodiments of the present application has been presented to illustrate the principles and implementations of the present application, and the above description of the embodiments is only provided to help understand the method and the core concept of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.
Claims (10)
- An aggregated payment method, comprising:receiving a payment request sent by a service system, wherein the payment request carries order information;determining a target payment mechanism according to the order information;and selecting a target payment authorization mode corresponding to the target payment mechanism to apply payment authorization to the target payment mechanism, and calling the payment of the target payment mechanism aiming at the payment request.
- The method of claim 1, wherein the order information comprises a terminal type identifier and a business party identity identifier; the determining a target payment mechanism according to the order information includes:determining a first payment mode set corresponding to the terminal type identifier, determining a second payment mode set corresponding to the service party identity identifier, and obtaining an available payment mode set, wherein the available payment mode set comprises an intersection of the first payment mode set and the second payment mode set;displaying an interface containing the set of available payment methods;and receiving a target payment mode selected by the user from the available payment mode set, and determining a target payment mechanism corresponding to the target payment mode.
- The method of claim 2, wherein selecting the target payment authorization method corresponding to the target payment authority applies for payment authorization from the target payment authority, comprising:determining a target payment authorization mode corresponding to the target payment mechanism according to the corresponding relation between the payment mechanism and the payment authorization mode:and applying for payment authorization to the target payment mechanism according to the target payment authorization mode.
- The method as claimed in claim 3, wherein the applying for payment authorization to the target payment authority according to the target payment authorization method comprises:and if the target payment authorization mode is a local authorization mode, generating a digital signature according to the order information.
- The method of claim 3, wherein applying for payment authorization from the target payment authority based on the target payment authorization manner comprises:if the target payment authorization mode is a server authorization mode, calling a payment authorization interface provided by the target payment mechanism, transmitting payment information required by the target payment mechanism into a server of the target payment mechanism, and applying for payment authorization to the server of the target payment mechanism.
- The method of claim 1, wherein receiving a payment request from a business system comprises:and receiving a payment request sent by a service system, calling a payment ordering interface, and transmitting the order information in the payment ordering interface.
- The method of any of claims 1-6, wherein after invoking payment by the target payment authority for the payment request, the method further comprises:and receiving a payment result notice sent by the target payment mechanism, and sending the payment result notice to the service system, wherein the payment result notice comprises a service order number and a payment state.
- An aggregated payment device, comprising:the first receiving unit is used for receiving a payment request sent by a service system, wherein the payment request carries order information;the determining unit is used for determining a target payment mechanism according to the order information;the payment authorization unit is used for selecting a target payment authorization mode corresponding to the target payment mechanism to apply for payment authorization to the target payment mechanism;and the payment unit is used for calling the payment of the target payment mechanism aiming at the payment request.
- A terminal device comprising a processor and a memory, the memory being configured to store a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any of claims 1 to 7.
- A computer-readable storage medium, characterized in that it stores a computer program comprising program instructions which, when executed by a processor, cause the processor to carry out the method according to any one of claims 1 to 7.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2020/096191 WO2021253185A1 (en) | 2020-06-15 | 2020-06-15 | Aggregate payment method and related products |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115516482A true CN115516482A (en) | 2022-12-23 |
Family
ID=79268922
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202080100567.XA Pending CN115516482A (en) | 2020-06-15 | 2020-06-15 | Aggregated payment method and related product |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN115516482A (en) |
| WO (1) | WO2021253185A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117078243A (en) * | 2023-10-16 | 2023-11-17 | 福建联迪商用设备有限公司 | Distributed payment processing method, system and electronic equipment |
| CN117391689A (en) * | 2023-10-18 | 2024-01-12 | 广东抱谷科技有限公司 | Payment control method, device and storage medium for multi-channel data processing |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114581095A (en) * | 2022-03-16 | 2022-06-03 | 网银在线（北京）科技有限公司 | Payment method, collection terminal and system |
| CN115018484A (en) * | 2022-06-06 | 2022-09-06 | 易联支付有限公司 | Skip payment method, aggregate payment platform, storage medium and computer equipment |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106372877A (en) * | 2016-08-31 | 2017-02-01 | 北京炎黄新星网络科技有限公司 | Integrated payment system |
| CN109102267A (en) * | 2017-06-21 | 2018-12-28 | 百联电子商务有限公司 | A kind of method and apparatus of polymerization payment |
| CN107578224A (en) * | 2017-09-13 | 2018-01-12 | 深圳前海乘势科技有限公司 | The method and device that multi-platform polymerization is paid |
| WO2019191365A1 (en) * | 2018-03-28 | 2019-10-03 | Averon Us, Inc. | Method and apparatus for facilitating performing payment option aggregation utilizing an automated authentication engine |
| CN109559102A (en) * | 2018-12-18 | 2019-04-02 | 厦门商集网络科技有限责任公司 | A kind of polymerization method of payment and terminal |
| CN109754234A (en) * | 2019-01-11 | 2019-05-14 | 北京顺丰同城科技有限公司 | A kind of polymerization method of payment and device |
| CN110232566A (en) * | 2019-06-21 | 2019-09-13 | 智联融数(北京)科技有限公司 | A kind of Polymeric electron method of payment that supporting a variety of means of payment and device |
-
2020
- 2020-06-15 CN CN202080100567.XA patent/CN115516482A/en active Pending
- 2020-06-15 WO PCT/CN2020/096191 patent/WO2021253185A1/en active Application Filing
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117078243A (en) * | 2023-10-16 | 2023-11-17 | 福建联迪商用设备有限公司 | Distributed payment processing method, system and electronic equipment |
| CN117078243B (en) * | 2023-10-16 | 2024-01-30 | 福建联迪商用设备有限公司 | Distributed payment processing method, system and electronic equipment |
| CN117391689A (en) * | 2023-10-18 | 2024-01-12 | 广东抱谷科技有限公司 | Payment control method, device and storage medium for multi-channel data processing |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021253185A1 (en) | 2021-12-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11887110B2 (en) | Methods and systems for processing transactions on a value dispensing device using a mobile device | |
| US10268810B2 (en) | Methods, apparatus and systems for securely authenticating a person depending on context | |
| CN115516482A (en) | Aggregated payment method and related product | |
| US11410146B2 (en) | Order processing | |
| CN110869961A (en) | System and method for securing sensitive credentials using transaction identifiers | |
| US20140019360A1 (en) | Method for online payment, and system and electronic device for implementing the same | |
| CN102968717A (en) | Electronic payment method, relevant device and system | |
| WO2012030836A2 (en) | Protecting express enrollment using a challenge | |
| KR20140125449A (en) | Transaction processing system and method | |
| CN107204957B (en) | Account binding and service processing method and device | |
| US20180089663A1 (en) | Electronic resource processing method and device | |
| JP2014096140A (en) | Method for payment processing, and system and electronic device for executing the same | |
| WO2019022963A1 (en) | Offline payment using virtual card account number | |
| US10304043B1 (en) | Multi-peripheral host device | |
| CN115461773A (en) | Tap to pay credit card bills | |
| CN113988844A (en) | Service subscription method, device and system | |
| CN104392349A (en) | Mobile payment method, device and system | |
| CN109801050B (en) | Mobile payment SDK and payment method for online mall | |
| CN112184343A (en) | Method and device for preventing electronic invoice from being stolen | |
| CN109801059B (en) | Mobile payment system and mobile payment method | |
| WO2021081704A1 (en) | Two-dimensional payment code management method and device, payment system, and storage medium | |
| US11620648B2 (en) | Payment method and system through generation of one-time payment-only number of real card linked with application | |
| TWM569016U (en) | Debit authorization system | |
| CN111080283A (en) | Payment method, payment system, and computer-readable storage medium | |
| CN116029718A (en) | Payment method, terminal, system, SIM card and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20230619 Address after: 1301, Office Building T2, Qianhai China Resources Financial Center, No. 55 Guiwan Fourth Road, Nanshan Street, Qianhai Shenzhen-Hong Kong Cooperation Zone, Shenzhen, Guangdong Province, 518052 Applicant after: Shenzhen Hefei Technology Co.,Ltd. Address before: 518052 2501, office building T2, Qianhai China Resources Financial Center, 55 guiwan 4th Road, Nanshan street, Qianhai Shenzhen Hong Kong cooperation zone, Shenzhen City, Guangdong Province Applicant before: Shenzhen Huantai Digital Technology Co.,Ltd. |