WO2021253185A1 - 聚合支付方法及相关产品 - Google Patents

聚合支付方法及相关产品 Download PDF

Info

Publication number
WO2021253185A1
WO2021253185A1 PCT/CN2020/096191 CN2020096191W WO2021253185A1 WO 2021253185 A1 WO2021253185 A1 WO 2021253185A1 CN 2020096191 W CN2020096191 W CN 2020096191W WO 2021253185 A1 WO2021253185 A1 WO 2021253185A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
target
institution
authorization
target payment
Prior art date
Application number
PCT/CN2020/096191
Other languages
English (en)
French (fr)
Inventor
吴航
Original Assignee
深圳市欢太数字科技有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 深圳市欢太数字科技有限公司 filed Critical 深圳市欢太数字科技有限公司
Priority to CN202080100567.XA priority Critical patent/CN115516482A/zh
Priority to PCT/CN2020/096191 priority patent/WO2021253185A1/zh
Publication of WO2021253185A1 publication Critical patent/WO2021253185A1/zh

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

Definitions

  • This application relates to the field of payment technology, in particular to an aggregate payment method and related products.
  • the embodiments of the present application provide an aggregate payment method and related products, which can improve the convenience of payment.
  • the first aspect of the embodiments of the present application provides an aggregate payment method, including:
  • the second aspect of the embodiments of the present application provides an aggregate payment device, including:
  • the first receiving unit is configured to receive a payment request sent by the business system, where the payment request carries order information;
  • the determining unit is used to determine the target payment institution according to the order information
  • a payment authorization unit configured to select a target payment authorization method corresponding to the target payment institution to apply for payment authorization to the target payment institution;
  • the payment unit is used to call the target payment institution to pay for the payment request.
  • a third aspect of the embodiments of the present application provides a terminal device, including a processor and a memory, the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to call the program The instruction executes the step instruction in the first aspect of the embodiment of the present application.
  • a fourth aspect of the embodiments of the present application provides a computer-readable storage medium, wherein the above-mentioned computer-readable storage medium stores a computer program for electronic data exchange, wherein the above-mentioned computer program enables a computer to execute Some or all of the steps described in one aspect.
  • the fifth aspect of the embodiments of the present application provides a computer program product, wherein the above-mentioned computer program product includes a non-transitory computer-readable storage medium storing a computer program, and the above-mentioned computer program is operable to cause a computer to execute as implemented in this application.
  • the computer program product may be a software installation package.
  • the aggregate payment device receives a payment request sent by the business system, the payment request carries order information; determines the target payment institution according to the order information; selects the target payment authorization method corresponding to the target payment institution to the The target payment institution applies for payment authorization, and calls the target payment institution to pay for the payment request.
  • the aggregate payment device can be connected to the business system and the payment institution, and the business system does not need to directly connect to the payment institution, which saves the workload of business system access payment and saves the time of business system access payment.
  • Figure 1 is a schematic structural diagram of an aggregate payment system provided by an embodiment of the present application.
  • FIG. 2 is a schematic flowchart of an aggregate payment method provided by an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of another aggregate payment method provided by 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 aggregate payment device provided by an embodiment of the application.
  • Fig. 6 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • the terminal devices involved in the embodiments of the present application may include various handheld devices with wireless communication functions, vehicle-mounted devices, wearable devices, computing devices or other processing devices connected to wireless modems, as well as various forms of user equipment (user equipment).
  • equipment UE
  • mobile station mobile station
  • terminal device terminal device
  • Figure 1 is a schematic structural diagram of an aggregate payment system provided by an embodiment of the application, including a business system, an aggregate payment device, and a payment institution.
  • the business system includes a business system front end and a business system backend. Payment front end and aggregate payment back end. When a user orders a product at the front end of the business system, the backend of the business system receives the information of the ordered product.
  • the first step the user initiates payment at the front end of the business system, and the aggregate payment front end displays the aggregate payment page; the second step: the user selects the desired payment method on the aggregate payment page, and initiates the payment on the aggregate payment front end; the third step: user confirmation After the payment method, the aggregate payment backstage will go to the corresponding payment institution to apply for authorization for the user.
  • the authorization information of the payment institution the user can confirm the payment at the payment institution;
  • Step 4 After the payment institution confirms the receipt result, the background notification method is adopted Notify the back-end user of the aggregate payment of the payment result;
  • Step 5 The aggregate payment sends the result of the user's payment to the back-end of the business system in the form of a back-end notification.
  • the front end of the business system can be carried in the terminal device, and the front end of the aggregate payment can also be carried in the terminal device.
  • the business system backend can be carried on the business system server, and the aggregate payment backend can be carried on the aggregate payment server.
  • a payment institution is a third-party payment institution (such as WeChat, Alipay) that holds a payment license or an institution (such as a bank) that is qualified to acquire orders.
  • Aggregate payment is a system or product that organizes multiple payment methods in a consistent process and operation mode to provide users with payment services.
  • the aggregate payment system in the embodiment of the present application provides a unified access platform with integrated multiple payment methods for the business system, hides the differences between different payment institutions, and saves the workload of the business system for access and payment.
  • the aggregate payment system does not deposit funds, and the funds are kept by payment institutions with acquiring qualifications, which increases the universality of the embodiments of this application. Since the business system and the user system of the payment institution are different, the user identification is also different, so the user identification is not a necessary item in the embodiment of the present application, which can reduce the dependence on the user.
  • the embodiment of the application uses the background notification as the only condition for successful payment to isolate it from the channel of the user's payment process, avoiding the uncertain state of the payment result and the attack on the payment result.
  • FIG. 2 is a schematic flowchart of an aggregate payment method provided by an embodiment of the present application.
  • the aggregate payment method may include the following steps.
  • the aggregate payment device receives a payment request sent by the business system, and the payment request carries order information.
  • users of aggregate payment can be divided into two categories: one category is individual users, that is, customers of the business side system, who are the party who completes the payment in the payment activity.
  • the other type is business parties, which are usually called merchants.
  • the payment request sent by the business system can be initiated by the customer of the business party system or by the merchant.
  • the order information may reflect some information of the payment request sent by the business system.
  • the order information may include payment information, such as the business party’s order number, product information, payment amount, etc.
  • a business order is an order generated by the ordering operation of the business system, and the order number of the business party is an order number generated by the business system that uniquely identifies the business order.
  • the order information may also optionally include one or a combination of user information, key payment information, and control information.
  • user information can include the user's identity token, mobile phone number, etc.
  • payment key information can include bank card number, point card number or password, etc.
  • control information can include terminal type identification, business party identification, payment scenario, payment method code Wait.
  • Order information is the information that needs to be passed in as defined by the aggregate payment device, and can be passed in through the payment order interface.
  • step 201 may include the following steps:
  • the aggregate payment device receives the payment request sent by the business system, calls the payment order interface, and transmits the order information into the payment order interface.
  • the order information that needs to be transmitted may be different.
  • the order information transmitted by a business system that supports webpage payment may include payment information and control information (for example, web browser identification, business party identification).
  • the order information transmitted through the business system of bank card or point card payment may include payment information and key payment information (for example, bank card number, point card number or password, etc.).
  • some payment institutions require user information such as one-time user tokens to be obtained and passed in, and some payment institutions require user information such as card numbers and mobile phone numbers held by users to be passed in.
  • the aggregate payment device determines a target payment institution according to the order information.
  • the aggregate payment device can determine the payment scenario according to the order information, and determine the payment institution supported by the payment scenario according to the payment scenario, and the user can select the target payment institution from the payment institutions supported by the payment scenario.
  • Different payment scenarios support different payment institutions.
  • Typical payment scenarios can include the following:
  • Mobile App payment scenario Individual users hold an app designated by the payment institution and complete the payment in the payment institution app, which is often used for online payment on the mobile terminal.
  • the payment institution supported by the payment scenario is the payment institution corresponding to the payment institution app.
  • Scan code payment scenario Individual users hold the app designated by the payment institution and scan the payment QR code generated by the business party to complete the payment. It is often used for cross-device payments (the order occurs on the A device and the payment is on the B device).
  • the payment institution supported by this payment scenario is the payment institution corresponding to the app designated by the payment institution held by the user.
  • Swipe payment scenario Individual users present the barcode or QR code issued by the payment institution, and the business party uses the scanning device to read the barcode to complete the payment, which is common in offline scenarios.
  • the payment institution supported by the payment scenario is the payment institution presented by the individual user.
  • Terminalless payment scenarios Individual users do not need to use any terminals. For example, individual users complete payment by swiping their faces, which is common in offline payment scenarios.
  • the payment institution supported by the payment scenario is the payment institution supported by the face payment.
  • Bank card or point card payment scenario The individual user directly enters the bank card or point card number and necessary information on the order page of the business party to complete the payment.
  • the payment institution supported by the payment scenario is the bank corresponding to the bank card.
  • the order information includes control information
  • the control information includes terminal type identification and service party identification
  • step 202 may include the following steps:
  • the aggregate payment device determines the first payment method set corresponding to the terminal type identifier, determines the second payment method set corresponding to the business party identity identifier, and obtains the available payment method set, and the available payment method set includes the The intersection of the first payment method set and the second payment method set;
  • the aggregate payment device displays an interface containing the set of available payment methods
  • the aggregate payment device receives the target payment method selected by the user from the set of available payment methods, and determines the target payment institution corresponding to the target payment method.
  • the aggregate payment device can identify the terminal type according to the terminal type identifier. For example, identifying whether the payment is initiated is a mobile phone or another device, an App or a browser on the mobile phone, an App of a business party or an App of a payment institution (such as the official account page of WeChat).
  • the identity of the business party may include the business party code.
  • the available payment methods can be selected according to the terminal type identification and the business party code. For example, the first payment method set supported by the terminal type identifier includes payment method 1, payment method 2, payment method 3, payment method 4, and payment method 5, and the second payment method set supported by the business party code corresponds to payment method 3, Payment method 5 and payment method 6, then the set of available payment methods includes payment method 3 and payment method 5.
  • a page opened in an app of a business party can support a large number of payment methods, but a page opened in an app of a payment institution usually only supports the payment method corresponding to the payment institution.
  • the payment methods in the set of available payment methods can be filled into the message format that can be recognized by the terminal, and the interface of the set of available payment methods can be displayed to the user for selection.
  • the user can return data in a specific format or a page.
  • a specific format such as JSON
  • the data format returned is different for different terminal devices.
  • the data that can be identified and processed by the user terminal type can be returned according to the terminal type.
  • step 202 may include the following steps:
  • the aggregation payment device determines the payment method set corresponding to the payment method code, and obtains the available payment method set;
  • the aggregate payment device displays an interface containing the set of available payment methods
  • the aggregate payment device receives the target payment method selected by the user from the set of available payment methods, and determines the target payment institution corresponding to the target payment method.
  • the set of all payment methods corresponding to the payment method code can be used as the set of available payment methods and displayed to the user for selection.
  • the aggregate payment method can determine the set of available payment methods supported by the terminal type identifier and the business party identity identifier for the user to choose, and determine the target payment institution corresponding to the target payment method selected by the user, and the business system does not need to be directly connected
  • the payment institution saves the workload of business system access payment, and saves the time of business system access payment.
  • the aggregate payment device selects the target payment authorization method corresponding to the target payment institution to apply for payment authorization to the target payment institution.
  • different payment structures may have different payment authorization methods. For example, some payment institutions only need to generate authorization locally, and some payment institutions require sending a request to their back-end server for authorization.
  • the aggregate payment device can select the target payment authorization method corresponding to the target payment institution to apply for payment authorization to the target payment institution according to the corresponding relationship between the payment institution and the payment authorization method. It can reduce or eliminate the impact of differences in payment authorization between different payment institutions on users, solve the need for business systems to use multiple payment methods, shorten the user's payment process, and improve the convenience of payment.
  • step 203 may include the following steps:
  • the aggregate payment device determines the target payment authorization method corresponding to the target payment institution according to the corresponding relationship between the payment institution and the payment authorization method:
  • the aggregate payment device applies to the target payment institution for payment authorization according to the target payment authorization method.
  • different payment institutions may have different payment authorization methods. For example, some payment institutions do not require payment authorization. Some payment institutions only need to generate authorization locally, and some payment institutions require sending a request to their back-end server for authorization.
  • the payment authorization method of each payment institution can be determined. After the target payment institution is determined, the target payment authorization method corresponding to the target payment institution can be determined according to the stored correspondence between the payment institution and the payment authorization method.
  • the aggregate payment method of this application can process payment authorizations of various payment institutions, reduce the workload of accessing multiple payment institutions, and save the time for the business system to access payment.
  • step (32) the aggregate payment device applies for payment authorization from the target payment institution according to the target payment authorization method, which may include the following steps:
  • the aggregate payment device If the target payment authorization method is a local authorization method, the aggregate payment device generates a digital signature according to the order information.
  • the aggregate payment device if the target authorized payment method is a local authorization method, for example, the target authorized payment method is Alipay payment, the aggregate payment device generates a digital signature according to the order information.
  • the local authorization method does not require authorization on the server of the target payment institution, which can shorten the payment authorization process and increase the speed of payment authorization.
  • a digital signature is some data attached to a data unit, or a cryptographic transformation of the data unit. This data or transformation allows the recipient of the data unit to confirm the source of the data unit and the integrity of the data unit and protect the data from being forged by someone (for example, the recipient).
  • the digital signature can be attached to the order information.
  • step (32) the aggregate payment device applies for payment authorization from the target payment institution according to the target payment authorization method, which may include the following steps:
  • the aggregating payment device calls the payment authorization interface provided by the target payment institution, transmits the payment information required by the target payment institution to the server of the target payment institution, and sends the payment information to the server of the target payment institution.
  • the server of the target payment institution applies for payment authorization.
  • the target payment authorization method is a server authorization method
  • the target authorization payment method is WeChat payment
  • the aggregate payment device calls the payment authorization interface provided by the WeChat payment institution to transmit the payment information required by the WeChat payment institution Access the server of the WeChat payment institution, and apply for payment authorization from the server of the WeChat payment institution.
  • the server authorization method requires authorization on the server of the target payment institution, and the server of the target payment institution can record authorization information in time, which can improve the security of payment authorization.
  • the aggregate payment device invokes the payment request made by the target payment institution for the payment request.
  • the aggregate payment device can complete the payment through the target payment institution for the payment request made by the target payment institution.
  • the aggregate payment device in the embodiment of this application does not perform specific payment actions, but completes the payment through the target payment institution.
  • the aggregate payment system does not deposit funds, and the funds are kept by payment institutions with acquiring qualifications, which increases the generality of the embodiments of this application. Adaptability.
  • the aggregate payment device can be connected to the business system and the payment institution, and the business system does not need to directly connect to the payment institution, which saves the workload of business system access payment and saves the time of business system access payment.
  • aggregate payment the impact of differences between different payment institutions on users is reduced or eliminated, and the need for the business system to use multiple methods for payment is solved, which can shorten the user's payment process and improve the convenience of payment.
  • FIG. 3 is a schematic flowchart of another aggregate payment method provided by an embodiment of the present application.
  • the aggregate payment method may include the following steps.
  • the aggregate payment device receives a payment request sent by the business system, and the payment request carries order information.
  • the aggregate payment device determines the target payment institution according to the order information.
  • the aggregate payment device selects a target payment authorization method corresponding to the target payment institution to apply for payment authorization to the target payment institution.
  • the aggregate payment device calls the target payment institution to pay for the payment request.
  • step 301 to step 304 in the embodiment of the present application reference may be made to step 201 to step 204 shown in FIG. 1, which will not be repeated here.
  • the aggregate payment device receives the payment result notification sent by the target payment institution, and sends the payment result notification to the business system.
  • the payment result notification includes the business order number and the payment status.
  • the target payment institution may send a payment result notification to the aggregate payment system, and the payment result notification may include the service order number and payment status.
  • the business 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 method.
  • the embodiment of the application uses a unified "payment result notification" interface to inform the business party of the payment result of the system.
  • the specific method may include: the aggregate payment device completes the payment result confirmation in a manner approved by the payment institution, and then initiates the payment result confirmation notification.
  • the embodiment of the present application uses the background notification as the only condition for successful payment to isolate it from the channel of the user's payment process, which can avoid the uncertain state of the payment result and the attack on the payment result, and improve the reliability and security of the payment.
  • the aggregate payment device can be connected to the business system and the payment institution, and the business system does not need to directly connect to the payment institution, which saves the workload of business system access payment and saves the time of business system access payment.
  • aggregate payment By means of aggregate payment, the impact of differences between different payment institutions on users is reduced or eliminated, and the need for the business system to use multiple methods for payment is solved, which can shorten the user's payment process and improve the convenience of payment.
  • background notification as the only condition for payment success, isolating it from the channel of the user's payment process, can avoid the uncertainty of the payment result and the attack on the payment result, and improve the reliability and security of the payment.
  • FIG. 4 is a usage scenario diagram of an aggregate payment provided by an embodiment of the present application.
  • the usage scenario is shown in Figure 4, including the business system order page, the aggregate payment display page, and the payment institution page.
  • the user completes the order on the order page of the business system, enters the aggregate payment display page when paying, and chooses a specific payment method to jump to the payment institution's app or page to make the payment.
  • This aggregate payment scenario can meet the diversified needs of business system payment methods, shorten the user's payment path, and increase the user's payment conversion rate.
  • the terminal device includes a hardware structure and/or software module corresponding to each function.
  • the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or computer software-driven hardware depends on the specific application and design constraint conditions of the technical solution. Professionals and technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of this application.
  • the embodiment of the present application may divide the terminal device into functional units according to the foregoing method examples.
  • each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing unit.
  • the above-mentioned integrated unit can be implemented in the form of hardware or software functional unit. It should be noted that the division of units in the embodiments of the present application is illustrative, and is only a logical function division, and there may be other division methods in actual implementation.
  • FIG. 5 is a schematic structural diagram of an aggregate payment device provided by an embodiment of the application.
  • the aggregate payment device 500 is applied to a terminal device.
  • the aggregate payment device 500 may include a first receiving unit 501 , The determination unit 502, the payment authorization unit 503 and the payment unit 504, wherein:
  • the first receiving unit 501 is configured to receive a payment request sent by a business system, where the payment request carries order information;
  • the determining unit 502 is configured to determine a target payment institution according to the order information
  • the payment authorization unit 503 is configured to select a target payment authorization method corresponding to the target payment institution to apply for payment authorization to the target payment institution;
  • the payment unit 504 is configured to call the target payment institution to pay for the payment request.
  • the order information includes a terminal type identifier and a business party identity identifier; the determining unit 502 determines a target payment institution according to the order information, specifically: determining a first payment method set corresponding to the terminal type identifier, Determine the second payment method set corresponding to the business party identity to obtain the available payment method set, where the available payment method set includes the intersection of the first payment method set and the second payment method set; the display includes the Interface of the set of available payment methods; receiving the target payment method selected by the user from the set of available payment methods, and determining the target payment institution corresponding to the target payment method.
  • the order information includes control information, and the control information includes a payment method code; the determining unit 502 determines a target payment institution according to the order information, specifically: determining a payment method set corresponding to the payment method code to obtain A set of available payment methods; displaying an interface containing the set of available payment methods; receiving a target payment method selected by the user from the set of available payment methods, and determining a target payment institution corresponding to the target payment method.
  • the payment authorization unit 503 selects the target payment authorization method corresponding to the target payment institution to apply to the target payment institution for payment authorization, specifically: determining the payment authorization method according to the corresponding relationship between the payment institution and the payment authorization method Target payment authorization method corresponding to the target payment institution: apply for payment authorization from the target payment institution according to the target payment authorization method.
  • the payment authorization unit 503 applies to the target payment institution for payment authorization according to the target payment authorization method, specifically: when the target payment authorization method is a local authorization method, according to the order information Generate a digital signature.
  • the payment authorization unit 503 applies for payment authorization from the target payment institution according to the target payment authorization method, specifically: when the target payment authorization method is a server authorization method, invoking the target payment
  • the payment authorization interface provided by the institution transmits the payment information required by the target payment institution to the server of the target payment institution, and applies for payment authorization from the server of the target payment institution.
  • the first receiving unit 501 receives the payment request sent by the business system, specifically: receiving the payment request sent by the business system, calling the payment order interface, and inputting the order information in the payment order interface .
  • the aggregate payment device 500 may also include a second receiving unit 505 and a sending unit 506;
  • the second receiving unit 505 is configured to receive a payment result notification sent by the target payment institution
  • the sending unit 506 is configured to send the payment result notification to the service system, and the payment result notification includes the service order number and payment status.
  • the determining unit 502, the payment authorization unit 503, and the payment unit 504 in the embodiment of the present application may be processors in the terminal device, and the first receiving unit 501, the second receiving unit 505, and the sending unit 506 may be processors in the terminal device. Communication Interface.
  • the aggregate payment device 500 may further include a storage unit for storing relevant information in the payment process, including business order number, payment order number, product information, payment amount, payment status, etc.
  • the storage unit 506 may be a memory in the terminal device (for example, a non-volatile memory).
  • the aggregate payment device can be connected to the business system and the payment institution, and the business system does not need to directly connect to the payment institution, which saves the workload of business system access payment and saves the time of business system access payment.
  • aggregate payment the impact of differences between different payment institutions on users is reduced or eliminated, and the need for the business system to use multiple methods for payment is solved, which can shorten the user's payment process and improve the convenience of payment.
  • FIG. 6 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • the terminal device 600 includes a processor 601 and a memory 602.
  • the processor 601 and the memory 602 can pass through a communication bus. 603 are connected to each other.
  • the communication bus 603 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc.
  • the communication bus 603 can be divided into an address bus, a data bus, a control bus, and so on. For ease of representation, only one thick line is used in FIG. 6, but it does not mean that there is only one bus or one type of bus.
  • the memory 602 is used to store a computer program.
  • the computer program includes program instructions.
  • the processor 601 is configured to call the program instructions.
  • the above program includes methods for executing the methods shown in FIGS. 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 used to control the execution of the above scheme programs.
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • the memory 602 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM), or other types that can store information and instructions
  • the dynamic storage device can also be electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), CD-ROM (Compact Disc Read-Only Memory, CD-ROM) or other optical disc storage, optical disc storage (Including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program codes in the form of instructions or data structures and can be used by a computer Any other media accessed, but not limited to this.
  • the memory can exist independently and is connected to the processor through a bus.
  • the memory can also be integrated with the processor.
  • the terminal device 600 may also include general components such as a communication interface 604 and an antenna, which are not described in detail here.
  • the terminal device can interface with the business system and the payment institution through the aggregate payment system, and the business system does not need to directly interface with the payment institution, which saves the workload of business system access payment and saves the time of business system access payment.
  • aggregate payment By means of aggregate payment, the impact of differences between different payment institutions on users is reduced or eliminated, and the need for business systems to use multiple payment methods is solved, which can shorten the user's payment process and improve the convenience of payment.
  • An embodiment of the present application also provides 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 any aggregate payment as recorded in the above method embodiments. Part or all of the steps of the method.
  • the embodiments of the present application also provide a computer program product.
  • the computer program product includes a non-transitory computer-readable storage medium storing a computer program.
  • the computer program enables a computer to execute any aggregate payment as recorded in the above method embodiments. Part or all of the steps of the method.
  • the disclosed device may be implemented in other ways.
  • the device embodiments described above are merely illustrative.
  • the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined or may be Integrate into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • each functional unit in each embodiment may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit can be implemented in the form of hardware or software program module.
  • the integrated unit is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer readable memory.
  • the technical solution of the present application essentially or the part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a memory.
  • a number of instructions are included to enable a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned memory includes: U disk, read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), mobile hard disk, magnetic disk, or optical disk and other media that can store program codes.
  • the program can be stored in a computer-readable memory, and the memory can include: a flash disk , Read-only memory, random access device, magnetic or optical disk, etc.

Abstract

一种聚合支付方法及相关产品，该聚合支付方法包括：接收业务系统发送的支付请求，支付请求携带订单信息（301）；根据订单信息确定目标支付机构（302）；选择与目标支付机构对应的目标支付授权方式向目标支付机构申请支付授权（303），调用目标支付机构针对支付请求的支付（304）。可以提高支付的便捷性。

Description

聚合支付方法及相关产品 技术领域
本申请涉及支付技术领域，具体涉及一种聚合支付方法及相关产品。
背景技术
电子支付在我国普及率非常高，己经成为日常生活必不可少的方式。目前市面上有数十家支付机构，包括第三方支付机构及各大银行，每个支付机构都有其自己的应用程序(application，App)，在支付过程中，支付流程很繁琐，支付便捷性较低。
发明内容
本申请实施例提供一种聚合支付方法及相关产品，可以提高支付的便捷性。
本申请实施例的第一方面提供了一种聚合支付方法，包括：
接收业务系统发送的支付请求，所述支付请求携带订单信息；
根据所述订单信息确定目标支付机构；
选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权，调用所述目标支付机构针对所述支付请求的支付。
本申请实施例的第二方面提供了一种聚合支付装置，包括：
第一接收单元，用于接收业务系统发送的支付请求，所述支付请求携带订单信息；
确定单元，用于根据所述订单信息确定目标支付机构；
支付授权单元，用于选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权；
支付单元，用于调用所述目标支付机构针对所述支付请求的支付。
本申请实施例的第三方面提供了一种终端设备，包括处理器和存储器，所 述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如本申请实施例第一方面中的步骤指令。
本申请实施例的第四方面提供了一种计算机可读存储介质，其中，上述计算机可读存储介质存储用于电子数据交换的计算机程序，其中，上述计算机程序使得计算机执行如本申请实施例第一方面中所描述的部分或全部步骤。
本申请实施例的第五方面提供了一种计算机程序产品，其中，上述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执行如本申请实施例第一方面中所描述的部分或全部步骤。该计算机程序产品可以为一个软件安装包。
本申请实施例中，聚合支付装置接收业务系统发送的支付请求，所述支付请求携带订单信息；根据所述订单信息确定目标支付机构；选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权，调用所述目标支付机构针对所述支付请求的支付。本申请实施例中，聚合支付装置可以对接业务系统与支付机构，业务系统无需直接对接支付机构，节省了业务系统接入支付的工作量，节省业务系统接入支付的时间。通过聚合支付的方式，减弱或消除不同支付机构间的差异给用户造成的影响，解决了业务系统采用多种方式进行支付的需求，可以缩短用户支付的流程，提高支付的便捷性。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种聚合支付系统的结构示意图；
图2是本申请实施例提供的一种聚合支付方法的流程示意图；
图3是本申请实施例提供的另一种聚合支付方法的流程示意图；
图4是本申请实施例提供的一种聚合支付的使用场景图；
图5为本申请实施例提供的一种聚合支付装置的结构示意图；
图6是本申请实施例提供的一种终端设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。
在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本申请所描述的实施例可以与其它实施例相结合。
本申请实施例所涉及到的终端设备可以包括各种具有无线通信功能的手持设备、车载设备、可穿戴设备、计算设备或连接到无线调制解调器的其他处理设备，以及各种形式的用户设备(user equipment，UE)，移动台(mobile station，MS)，终端设备(terminal device)等等。为方便描述，上面提到的设备统称为终端设备。
请参阅图1，图1是本申请实施例提供的一种聚合支付系统的结构示意图，包括业务系统、聚合支付装置和支付机构，业务系统包括业务系统前端和业务系统后台，聚合支付装置包括聚合支付前端和聚合支付后台。当用户在业务系 统前端订购商品时，业务系统后台接收订购商品的信息。第一步：用户在业务系统前端发起付款，聚合支付前端展示聚合支付页面；第二步：用户在聚合支付页面上选择想用的支付方式，在聚合支付前端发起付款；第三步：用户确认支付方式后，聚合支付后台会到相应的支付机构为用户申请授权，通过支付机构的授权信息，用户可以在支付机构确认付款；第四步：支付机构确认收单结果后，采用后台通知的方式通知聚合支付后台用户支付结果；第五步：聚合支付将用户付款的结果，采用后台通知的方式发送到业务系统后台。
业务系统前端可以承载在终端设备中，聚合支付前端也可以承载在终端设备中。业务系统后台可以承载在业务系统服务器中，聚合支付后台可以承载在聚合支付服务器。支付机构是持有支付牌照的第三方支付机构(如微信、支付宝)或有收单资质的机构(如银行)。
聚合支付是将多种支付方式以一致的流程和操作方式组织，为用户提供支付服务的系统或产品。
本申请实施例中的聚合支付系统为业务系统提供了集成的多种支付方式的统一接入平台，隐藏了不同支付机构间的差异，节省了业务系统接入支付的工作量。聚合支付系统中不沉淀资金，资金由具有收单资质的支付机构保管，增加了本申请实施例的普适性。由于业务系统与支付机构的用户体系不同，用户标识也是不一样的，因此用户标识在本申请实施例中不是一个必要项，这样可以减少对用户的依赖。本申请实施例使用后台通知作为支付成功的唯一条件，使其与用户支付过程的信道隔离，避免了支付结果的不确定状态及针对支付结果的攻击。
请参阅图2，图2是本申请实施例提供的一种聚合支付方法的流程示意图。如图2所示，该聚合支付方法可以包括如下步骤。
201，聚合支付装置接收业务系统发送的支付请求，支付请求携带订单信息。
本申请实施例中，聚合支付的用户可以分为两类：一类是个人用户，即业务方系统的客户，在支付活动中是完成付款的一方。另一类是业务方，通常也 称之为商户。业务系统发送的支付请求可以是业务方系统的客户发起的，也可以是商户发起的。
订单信息可以反映业务系统发送的支付请求的一些信息，订单信息可以包括支付信息，比如业务方的订单号，商品信息，付款金额等。
业务订单是由业务系统订购操作生成的订单，业务方的订单号是由业务系统生成的唯一标识业务订单的订单号。
可选的，订单信息还可以选择性的包括用户信息、支付关键信息、控制信息中的一种或多种组合。
其中，用户信息可以包括用户的身份token、手机号等；支付关键信息可以包括银行卡卡号，点卡卡号或密码等；控制信息可以包括终端类型标识，业务方身份标识，支付场景，支付方式代码等。
订单信息是由聚合支付装置定义的需要传入的信息，可以在支付下单接口传入。
可选的，步骤201可以包括如下步骤：
聚合支付装置接收业务系统发送的支付请求，调用支付下单接口，在所述支付下单接口中传入所述订单信息。
本申请实施例中，不同的业务系统在发送支付请求时，需要传输的订单信息有可能不同。比如，支持网页支付的业务系统传入的订单信息可以包括支付信息和控制信息(比如，web浏览器标识，业务方身份标识)。又比如，通过银行卡或点卡支付的业务系统传入的订单信息可以包括支付信息和支付关键信息(比如，银行卡卡号，点卡卡号或密码等)。又比如，有些支付机构要求获取并传入一次性的用户token等用户信息，有些支付机构要求传入用户持有的卡号及手机号等用户信息。
202，聚合支付装置根据订单信息确定目标支付机构。
本申请实施例中，聚合支付装置可以根据订单信息判断支付场景，根据支付场景确定该支付场景支持的支付机构，用户可以从该支付场景支持的支付机构中选择目标支付机构。不同的支付场景支持的支付机构可以不同。
典型的支付场景可以包括如下几种：
(1)手机App支付场景：个人用户持有支付机构指定的app，在支付机构app内完成付款，常用于移动端线上支付。该支付场景支持的支付机构为支付机构app对应的支付机构。
(2)网页支付(H5支付)场景：个人用户通过网页登陆到支付机构指定的页面，在页面上完成支付，常见于PC端线上支付。该支付场景支持的支付机构为个人用户通过网页登陆到支付机构。
(3)扫码支付场景：个人用户持有支付机构指定的app，扫描业务方生成的支付二维码完成付款，常用于跨设备(订购发生于A设备，付款于B设备)支付。该支付场景支持的支付机构为人用户持有支付机构指定的app对应的支付机构。
(4)刷卡支付场景：个人用户出示支付机构的签发的条码或二维码，业务方使用扫码设备读取条码完成收款，常见于线下场景。该支付场景支持的支付机构为个人用户出示的支付机构。
(5)无终端支付场景：个人用户无需使用任何终端，例如个人用户通过刷脸完成支付，常见于线下支付场景。该支付场景支持的支付机构为刷脸支付所支持的支付机构。
(6)银行卡或点卡支付场景：个人用户在业务方订购页面上中直接输入银行卡或点卡卡号及必要信息，完成支付。该支付场景支持的支付机构为该银行卡对应的银行。
可选的，所述订单信息包括控制信息，控制信息包括终端类型标识和业务方身份标识；步骤202可以包括如下步骤：
(11)聚合支付装置确定所述终端类型标识对应的第一支付方式集合，确定所述业务方身份标识对应的第二支付方式集合，得到可用支付方式集合，所述可用支付方式集合包括所述第一支付方式集合与所述第二支付方式集合的交集；
(12)聚合支付装置展示包含所述可用支付方式集合的界面；
(13)聚合支付装置接收用户从所述可用支付方式集合中选择的目标支付方式，确定所述目标支付方式对应的目标支付机构。
本申请实施例中，如果业务系统传入了终端类型标识和业务方身份标识，聚合支付装置可以根据终端类型标识识别终端类型。例如，识别发起支付的是手机还是其它设备，在手机上是App或浏览器，是处于业务方App还是支付机构的App(比如微信的公从号页面)中。
业务方身份标识可以包括业务方编码。可以根据终端类型标识及业务方编码选择可用的支付方式。比如，终端类型标识对应支持的第一支付方式集合包括支付方式1、支付方式2、支付方式3、支付方式4和支付方式5，业务方编码对应支持的第二支付方式集合包括支付方式3、支付方式5和支付方式6，则可用支付方式集合包括支付方式3和支付方式5。
例如，在业务方的App中打开的页面可以支持大量的支付方式，但在支付机构的App中打开的页面通常只支持支付机构对应的支付方式。
可以将可用支付方式集合中的支付方式填入终端可以识别的报文格式中，通过可用支付方式集合的界面展示给用户进行选择。
可选的，用户在APP页面中选择目标支付方式后，可以返回特定格式的数据或一个页面。比如，为App返回特定格式的数据(如JSON)，或为浏览器返回一个页面，针对不同的终端设备返回的数据格式不同。可以根据终端类型返回用户终端类型可以识别处理的数据。
可选的，所述订单信息包括控制信息，控制信息包括支付方式代码；步骤202可以包括如下步骤：
(21)聚合支付装置确定所述支付方式代码对应的支付方式集合，得到可用支付方式集合；
(22)聚合支付装置展示包含所述可用支付方式集合的界面；
(23)聚合支付装置接收用户从所述可用支付方式集合中选择的目标支付方式，确定所述目标支付方式对应的目标支付机构。
本申请实施例中，如果业务系统传入了其支持的支付方式的支付方式代 码，则可以将该支付方式代码对应的所有支付方式的集合作为可用支付方式集合，并展示给用户进行选择。
本申请实施例中，聚合支付方式可以根据终端类型标识和业务方身份标识确定支持的可用支付方式集合供用户进行选择，并确定用户选择的目标支付方式对应的目标支付机构，业务系统无需直接对接支付机构，节省了业务系统接入支付的工作量，节省业务系统接入支付的时间。
203，聚合支付装置选择与目标支付机构对应的目标支付授权方式向目标支付机构申请支付授权。
本申请实施例中，不同的支付结构，其支付授权方式也可能不同。比如，某些支付机构只需要本地生成授权，某些支付机构则要求发送请求到其后端服务器上进行授权。
聚合支付装置可以根据支付机构与支付授权方式的对应关系来选择与目标支付机构对应的目标支付授权方式向目标支付机构申请支付授权。可以减弱或消除不同支付机构间的支付授权的差异给用户造成的影响，解决了业务系统采用多种方式进行支付的需求，可以缩短用户支付的流程，提高支付的便捷性。
可选的，步骤203可以包括如下步骤：
(31)聚合支付装置根据支付机构与支付授权方式的对应关系确定与所述目标支付机构对应的目标支付授权方式：
(32)聚合支付装置根据所述目标支付授权方式向所述目标支付机构申请支付授权。
本申请实施例中，不同的支付机构的支付授权的方式可能不同。比如，某些支付机构无需支付授权。某些支付机构只需要本地生成授权，某些支付机构则要求发送请求到其后端服务器上进行授权。每个支付机构的支付授权方式都可以确定，当确定目标支付机构后，即可以根据存储的支付机构与支付授权方式的对应关系确定与所述目标支付机构对应的目标支付授权方式。本申请的聚合支付方式可以处理各种支付机构的支付授权，减少接入多个支付机构的工作量，节省业务系统接入支付的时间。
可选的，步骤(32)中，聚合支付装置根据所述目标支付授权方式向所述目标支付机构申请支付授权，可以包括如下步骤：
若所述目标支付授权方式为本地授权方式，聚合支付装置根据所述订单信息生成数字签名。
本申请实施例中，如果目标授权支付方式为本地授权方式，比如，目标授权支付方式为支付宝支付，聚合支付装置根据所述订单信息生成数字签名。本地授权方式无需在目标支付机构的服务器进行授权，可以缩短支付授权的流程，提高支付授权的速度。数字签名是附加在数据单元上的一些数据，或是对数据单元所作的密码变换。这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据，防止被人(例如接收者)进行伪造。比如，数字签名可以附加在订单信息上。
可选的，步骤(32)中，聚合支付装置根据所述目标支付授权方式向所述目标支付机构申请支付授权，可以包括如下步骤：
若所述目标支付授权方式为服务器授权方式，聚合支付装置调用所述目标支付机构提供的支付授权接口，将所述目标支付机构需要的支付信息传入所述目标支付机构的服务器，向所述目标支付机构的服务器申请支付授权。
本申请实施例中，如果目标支付授权方式为服务器授权方式，比如，目标授权支付方式为微信支付，聚合支付装置调用微信支付机构提供的支付授权接口，将所述微信支付机构需要的支付信息传入所述微信支付机构的服务器，向所述微信支付机构的服务器申请支付授权。服务器授权方式需在目标支付机构的服务器进行授权，目标支付机构的服务器可以及时记录授权信息，可以提高支付授权的安全性。
204，聚合支付装置调用目标支付机构针对支付请求的支付。
本申请实施例中，当支付授权完成后，聚合支付装置可以目标支付机构针对支付请求的支付，通过目标支付机构完成支付。本申请实施例的聚合支付装置不执行具体的支付动作，而是通过目标支付机构完成支付，聚合支付系统不沉淀资金，资金由具有收单资质的支付机构保管，增加了本申请实施例的普适 性。
本申请实施例中，聚合支付装置可以对接业务系统与支付机构，业务系统无需直接对接支付机构，节省了业务系统接入支付的工作量，节省业务系统接入支付的时间。通过聚合支付的方式，减弱或消除不同支付机构间的差异给用户造成的影响，解决了业务系统采用多种方式进行支付的需求，可以缩短用户支付的流程，提高支付的便捷性。
请参阅图3，图3是本申请实施例提供的另一种聚合支付方法的流程示意图。如图3所示，该聚合支付方法可以包括如下步骤。
301，聚合支付装置接收业务系统发送的支付请求，支付请求携带订单信息。
302，聚合支付装置根据订单信息确定目标支付机构。
303，聚合支付装置选择与目标支付机构对应的目标支付授权方式向目标支付机构申请支付授权。
304，聚合支付装置调用目标支付机构针对支付请求的支付。
本申请实施例中的步骤301至步骤304的具体实施可以参见图1所示的步骤201至步骤204，此处不再赘述。
305，聚合支付装置接收目标支付机构发送的支付结果通知，将支付结果通知发送至业务系统，支付结果通知包含业务订单号和支付状态。
本申请实施例中，当目标支付机构完成支付操作后，目标支付机构可以向聚合支付系统发送支付结果通知，支付结果通知可以包括业务订单号和支付状态。业务订单号是聚合支付装置根据支付请求生成的，支付状态可以包括支付成功或支付失败。支付结果通知为后台通知的方式。
本申请实施例使用统一的“支付结果通知”接口告知业务方系统付款结果。具体做法可以包括：由聚合支付装置以支付机构认可的方式完成支付结果确认，然后发起支付结果确认通知。本申请实施例使用后台通知作为支付成功的唯一条件，使其与用户支付过程的信道隔离，可以避免了支付结果的不确定状态及针对支付结果的攻击，提高支付的可靠性和安全性。
本申请实施例中，聚合支付装置可以对接业务系统与支付机构，业务系统无需直接对接支付机构，节省了业务系统接入支付的工作量，节省业务系统接入支付的时间。通过聚合支付的方式，减弱或消除不同支付机构间的差异给用户造成的影响，解决了业务系统采用多种方式进行支付的需求，可以缩短用户支付的流程，提高支付的便捷性。使用后台通知作为支付成功的唯一条件，使其与用户支付过程的信道隔离，可以避免了支付结果的不确定状态及针对支付结果的攻击，提高支付的可靠性和安全性。
请参阅图4，图4是本申请实施例提供的一种聚合支付的使用场景图。该使用场景如图4所示，包括业务系统订购页面，聚合支付展示页面和支付机构页面。用户在业务系统订购页面上完成订购，付款时进入聚合支付展示页面，选择具体的支付方式则跳转到支付机构的app或页面进行支付。该聚合支付场景可以满足业务系统支付手段多样化的需求，缩短用户支付路径，提高用户支付转化率。
上述主要从方法侧执行过程的角度对本申请实施例的方案进行了介绍。可以理解的是，终端设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所提供的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对终端设备进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
与上述一致的，请参阅图5，图5为本申请实施例提供的一种聚合支付装 置的结构示意图，该聚合支付装置500应用于终端设备，该聚合支付装置500可以包括第一接收单元501、确定单元502、支付授权单元503和支付单元504，其中：
第一接收单元501，用于接收业务系统发送的支付请求，所述支付请求携带订单信息；
确定单元502，用于根据所述订单信息确定目标支付机构；
支付授权单元503，用于选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权；
支付单元504，用于调用所述目标支付机构针对所述支付请求的支付。
可选的，所述订单信息包括终端类型标识和业务方身份标识；所述确定单元502根据所述订单信息确定目标支付机构，具体为：确定所述终端类型标识对应的第一支付方式集合，确定所述业务方身份标识对应的第二支付方式集合，得到可用支付方式集合，所述可用支付方式集合包括所述第一支付方式集合与所述第二支付方式集合的交集；展示包含所述可用支付方式集合的界面；接收用户从所述可用支付方式集合中选择的目标支付方式，确定所述目标支付方式对应的目标支付机构。
可选的，所述订单信息包括控制信息，控制信息包括支付方式代码；所述确定单元502根据所述订单信息确定目标支付机构，具体为：确定所述支付方式代码对应的支付方式集合，得到可用支付方式集合；展示包含所述可用支付方式集合的界面；接收用户从所述可用支付方式集合中选择的目标支付方式，确定所述目标支付方式对应的目标支付机构。
可选的，所述支付授权单元503选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权，具体为：根据支付机构与支付授权方式的对应关系确定与所述目标支付机构对应的目标支付授权方式：根据所述目标支付授权方式向所述目标支付机构申请支付授权。
可选的，所述支付授权单元503根据所述目标支付授权方式向所述目标支付机构申请支付授权，具体为：在所述目标支付授权方式为本地授权方式的情 况下，根据所述订单信息生成数字签名。
可选的，所述支付授权单元503根据所述目标支付授权方式向所述目标支付机构申请支付授权，具体为：在所述目标支付授权方式为服务器授权方式的情况下，调用所述目标支付机构提供的支付授权接口，将所述目标支付机构需要的支付信息传入所述目标支付机构的服务器，向所述目标支付机构的服务器申请支付授权。
可选的，所述第一接收单元501接收业务系统发送的支付请求，具体为：接收业务系统发送的支付请求，调用支付下单接口，在所述支付下单接口中传入所述订单信息。
该聚合支付装置500还可以包括第二接收单元505和发送单元506；
所述第二接收单元505，用于接收所述目标支付机构发送的支付结果通知；
所述发送单元506，用于将所述支付结果通知发送至所述业务系统，所述支付结果通知包含业务订单号和支付状态。
其中，本申请实施例中的确定单元502、支付授权单元503和支付单元504可以是终端设备中的处理器，第一接收单元501、第二接收单元505和发送单元506可以是终端设备中的通信接口。
可选的，该聚合支付装置500还可以包括存储单元，存储单元用于保存支付过程中的相关信息，包括业务订单号，支付订单号，商品信息，支付金额，支付状态等。存储单元506可以是终端设备中的存储器(比如，非易失性存储器)。
本申请实施例中，聚合支付装置可以对接业务系统与支付机构，业务系统无需直接对接支付机构，节省了业务系统接入支付的工作量，节省业务系统接入支付的时间。通过聚合支付的方式，减弱或消除不同支付机构间的差异给用户造成的影响，解决了业务系统采用多种方式进行支付的需求，可以缩短用户支付的流程，提高支付的便捷性。
请参阅图6，图6是本申请实施例提供的一种终端设备的结构示意图，如 图6所示，该终端设备600包括处理器601和存储器602，处理器601、存储器602可以通过通信总线603相互连接。通信总线603可以是外设部件互连标准(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，简称EISA)总线等。通信总线603可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。存储器602用于存储计算机程序，计算机程序包括程序指令，处理器601被配置用于调用程序指令，上述程序包括用于执行图2至图3所示的方法。
处理器601可以是通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制以上方案程序执行的集成电路。
存储器602可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
此外，该终端设备600还可以包括通信接口604、天线等通用部件，在此不再详述。
本申请实施例中，终端设备可以通过聚合支付系统对接业务系统与支付机构，业务系统无需直接对接支付机构，节省了业务系统接入支付的工作量，节省业务系统接入支付的时间。通过聚合支付的方式，减弱或消除不同支付机构间的差异给用户造成的影响，解决了业务系统采用多种方式进行支付的需求， 可以缩短用户支付的流程，提高支付的便捷性。
本申请实施例还提供一种计算机可读存储介质，其中，该计算机可读存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任何一聚合支付方法的部分或全部步骤。
本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，该计算机程序使得计算机执行如上述方法实施例中记载的任何一聚合支付方法的部分或全部步骤。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在申请明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元 中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。
所述集成的单元如果以软件程序模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器、随机存取器、磁盘或光盘等。
以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

  1. 一种聚合支付方法，其特征在于，包括：
    接收业务系统发送的支付请求，所述支付请求携带订单信息；
    根据所述订单信息确定目标支付机构；
    选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权，调用所述目标支付机构针对所述支付请求的支付。
  2. 根据权利要求1所述的方法，其特征在于，所述订单信息包括终端类型标识和业务方身份标识；所述根据所述订单信息确定目标支付机构，包括：
    确定所述终端类型标识对应的第一支付方式集合，确定所述业务方身份标识对应的第二支付方式集合，得到可用支付方式集合，所述可用支付方式集合包括所述第一支付方式集合与所述第二支付方式集合的交集；
    展示包含所述可用支付方式集合的界面；
    接收用户从所述可用支付方式集合中选择的目标支付方式，确定所述目标支付方式对应的目标支付机构。
  3. 根据权利要求2所述的方法，其特征在于，所述选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权，包括：
    根据支付机构与支付授权方式的对应关系确定与所述目标支付机构对应的目标支付授权方式：
    根据所述目标支付授权方式向所述目标支付机构申请支付授权。
  4. 根据权利要求3所述的方法，其特征在于，所述根据所述目标支付授权方式向所述目标支付机构申请支付授权，包括：
    若所述目标支付授权方式为本地授权方式，根据所述订单信息生成数字签名。
  5. 根据权利要求3所述的方法，其特征在于，所述根据所述目标支付授权方式向所述目标支付机构申请支付授权，包括：
    若所述目标支付授权方式为服务器授权方式，调用所述目标支付机构提供的支付授权接口，将所述目标支付机构需要的支付信息传入所述目标支付机构的服务器，向所述目标支付机构的服务器申请支付授权。
  6. 根据权利要求1所述的方法，其特征在于，所述接收业务系统发送的支付请求，包括：
    接收业务系统发送的支付请求，调用支付下单接口，在所述支付下单接口中传入所述订单信息。
  7. 根据权利要1～6任一项所述的方法，其特征在于，所述调用所述目标支付机构针对所述支付请求的支付之后，所述方法还包括：
    接收所述目标支付机构发送的支付结果通知，将所述支付结果通知发送至所述业务系统，所述支付结果通知包含业务订单号和支付状态。
  8. 一种聚合支付装置，其特征在于，包括：
    第一接收单元，用于接收业务系统发送的支付请求，所述支付请求携带订单信息；
    确定单元，用于根据所述订单信息确定目标支付机构；
    支付授权单元，用于选择与所述目标支付机构对应的目标支付授权方式向所述目标支付机构申请支付授权；
    支付单元，用于调用所述目标支付机构针对所述支付请求的支付。
  9. 一种终端设备，其特征在于，包括处理器和存储器，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用 所述程序指令，执行如权利要求1～7任一项所述的方法。
  10. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1～7任一项所述的方法。
PCT/CN2020/096191 2020-06-15 2020-06-15 聚合支付方法及相关产品 WO2021253185A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202080100567.XA CN115516482A (zh) 2020-06-15 2020-06-15 聚合支付方法及相关产品
PCT/CN2020/096191 WO2021253185A1 (zh) 2020-06-15 2020-06-15 聚合支付方法及相关产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/096191 WO2021253185A1 (zh) 2020-06-15 2020-06-15 聚合支付方法及相关产品

Publications (1)

Publication Number Publication Date
WO2021253185A1 true WO2021253185A1 (zh) 2021-12-23

Family

ID=79268922

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/096191 WO2021253185A1 (zh) 2020-06-15 2020-06-15 聚合支付方法及相关产品

Country Status (2)

Country Link
CN (1) CN115516482A (zh)
WO (1) WO2021253185A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114581095A (zh) * 2022-03-16 2022-06-03 网银在线（北京）科技有限公司 一种支付的方法、收款终端和系统
CN115018484A (zh) * 2022-06-06 2022-09-06 易联支付有限公司 跳转支付方法、聚合支付平台、存储介质及计算机设备

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117078243B (zh) * 2023-10-16 2024-01-30 福建联迪商用设备有限公司 一种分布式支付处理方法、系统及电子设备
CN117391689A (zh) * 2023-10-18 2024-01-12 广东抱谷科技有限公司 多渠道数据处理的支付控制方法、设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106372877A (zh) * 2016-08-31 2017-02-01 北京炎黄新星网络科技有限公司 一种聚合支付系统
CN107578224A (zh) * 2017-09-13 2018-01-12 深圳前海乘势科技有限公司 多平台聚合支付的方法及装置
CN109102267A (zh) * 2017-06-21 2018-12-28 百联电子商务有限公司 一种聚合支付的方法及设备
CN109559102A (zh) * 2018-12-18 2019-04-02 厦门商集网络科技有限责任公司 一种聚合支付方法及终端
CN109754234A (zh) * 2019-01-11 2019-05-14 北京顺丰同城科技有限公司 一种聚合支付方法及装置
CN110232566A (zh) * 2019-06-21 2019-09-13 智联融数(北京)科技有限公司 一种支持多种支付方式的聚合电子支付方法和装置
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

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106372877A (zh) * 2016-08-31 2017-02-01 北京炎黄新星网络科技有限公司 一种聚合支付系统
CN109102267A (zh) * 2017-06-21 2018-12-28 百联电子商务有限公司 一种聚合支付的方法及设备
CN107578224A (zh) * 2017-09-13 2018-01-12 深圳前海乘势科技有限公司 多平台聚合支付的方法及装置
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 (zh) * 2018-12-18 2019-04-02 厦门商集网络科技有限责任公司 一种聚合支付方法及终端
CN109754234A (zh) * 2019-01-11 2019-05-14 北京顺丰同城科技有限公司 一种聚合支付方法及装置
CN110232566A (zh) * 2019-06-21 2019-09-13 智联融数(北京)科技有限公司 一种支持多种支付方式的聚合电子支付方法和装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114581095A (zh) * 2022-03-16 2022-06-03 网银在线（北京）科技有限公司 一种支付的方法、收款终端和系统
CN115018484A (zh) * 2022-06-06 2022-09-06 易联支付有限公司 跳转支付方法、聚合支付平台、存储介质及计算机设备

Also Published As

Publication number Publication date
CN115516482A (zh) 2022-12-23

Similar Documents

Publication Publication Date Title
US20220318799A1 (en) Systems And Methods For Using A Transaction Identifier To Protect Sensitive Credentials
WO2021253185A1 (zh) 聚合支付方法及相关产品
US11941615B2 (en) Method and system for transmitting credentials
US10268810B2 (en) Methods, apparatus and systems for securely authenticating a person depending on context
US10764269B2 (en) Method and system for creating a unique identifier
US20170364910A1 (en) System and method to push payment to beneficiary account using an alias
CN102754116B (zh) 基于令牌的交易认证
US20150254672A1 (en) Processing authorization requests
US20150371221A1 (en) Two factor authentication for invoicing payments
US20160034891A1 (en) Method and system for activating credentials
US20160098699A1 (en) User-friendly mobile payments system
WO2018208443A1 (en) Secure remote transaction system using mobile devices
US10769631B2 (en) Providing payment credentials securely for telephone order transactions
US10304043B1 (en) Multi-peripheral host device
CN111314343B (zh) 账号管理方法、装置及可读存储介质
US11049101B2 (en) Secure remote transaction framework
WO2016138743A1 (zh) 一种实现安全支付的方法、移动终端和支付认证服务端
CN113988844A (zh) 业务签约方法、装置和系统
CN109801050B (zh) 一种用于在线商城的移动支付sdk和支付方法
WO2021081704A1 (zh) 支付二维码管理方法、设备、支付系统以及存储介质
CA3147130A1 (en) System for encoding resource access credential in barcode
US20190080302A1 (en) Payment system for facilitating delivery transactions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20940879

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 12.05.2023)

122 Ep: pct application non-entry in european phase

Ref document number: 20940879

Country of ref document: EP

Kind code of ref document: A1