WO2023178924A1 - 支付方法、用户终端、装置、设备、系统及介质 - Google Patents

支付方法、用户终端、装置、设备、系统及介质 Download PDF

Info

Publication number
WO2023178924A1
WO2023178924A1 PCT/CN2022/115584 CN2022115584W WO2023178924A1 WO 2023178924 A1 WO2023178924 A1 WO 2023178924A1 CN 2022115584 W CN2022115584 W CN 2022115584W WO 2023178924 A1 WO2023178924 A1 WO 2023178924A1
Authority
WO
WIPO (PCT)
Prior art keywords
host program
payment
platform
sdk
target
Prior art date
Application number
PCT/CN2022/115584
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 中国银联股份有限公司
Publication of WO2023178924A1 publication Critical patent/WO2023178924A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems

Definitions

  • This application belongs to data processing, and in particular relates to a payment method, user terminal, device, equipment, system and medium.
  • each card issuer or other institution develops and provides users with applications so that users can complete electronic payments through the applications.
  • Embodiments of the present application provide a payment method, user terminal, device, equipment, system and medium, which can uniformly manage payments and reduce the difficulty of payment management.
  • inventions of the present application provide a payment method, which is applied to a payment system.
  • the payment system includes a user terminal, a network-wide payment platform and a host program platform.
  • the user terminal has an e-commerce application and a third party integrated with the e-commerce application.
  • SDK software development kit
  • the e-commerce application belongs to the first entity
  • the host program belongs to the second entity
  • the first SDK and the second SDK belong to the third entity.
  • the method includes: when the e-commerce application triggers payment, the user terminal calls the first SDK to interact with the entire network payment platform to obtain a first host program list.
  • the first host program list includes at least some hosts supported by the entire network payment platform.
  • the host program identifier of the program when calling the first SDK to determine the target host program in the first host program list, the user terminal calls up the target host program; the user terminal calls the second SDK through the target host program to interact with the entire network payment platform , the entire network payment platform interacts with the host program platform, and the host program platform performs the resource deduction of the target card to complete the payment of the target card.
  • the target card is a resource card bound to the target host program.
  • embodiments of the present application provide a payment method, which is applied to a user terminal.
  • the user terminal has an e-commerce application, a first software development tool kit SDK integrated with the e-commerce application, a host program, and a first software development kit SDK integrated with the host program.
  • Second SDK Second SDK
  • the method includes: when the e-commerce application triggers payment, calling the first SDK to obtain a first host program list from the entire network payment platform.
  • the first host program list includes host programs of at least some host programs supported by the entire network payment platform. identification; when the first SDK is called to determine the target host program in the first host program list, the target host program is called; the second SDK is called through the target host program to interact with the entire network payment platform, so that the entire network payment platform interacts with The host program platform interacts to complete the payment of the target card.
  • the target card is a resource card bound to the target host program.
  • embodiments of the present application provide a payment method, which is applied to the entire network payment platform.
  • the method includes: when the e-commerce application of the user terminal triggers payment, adding a payment method to the user terminal that is integrated with the e-commerce application.
  • the first software development tool kit SDK provides a first host program list.
  • the user terminal has an e-commerce application, a first SDK, a host program and a second SDK integrated with the host program.
  • the first host program list includes all the payment platforms supported by the entire network.
  • the host program identifier of at least part of the host program is used to make the user terminal call the first SDK to determine and call up the target host program; interact with the second SDK and the host program platform called by the user terminal through the target host program to complete the payment of the target card,
  • the target card is a resource card bound to the target host program.
  • embodiments of the present application provide a payment method, which is applied to the host program platform.
  • the method includes: when the e-commerce application of the user terminal triggers payment, interacts with the entire network payment platform to determine the payment method.
  • Target card The user terminal has an e-commerce application, a first software development kit SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the target card is a card bound to the target host program.
  • the resource card and the target card are determined based on the second SDK of the target host program called by the user terminal and the entire network payment platform.
  • the target host program is the host program determined in the first host program list by the user terminal calling the first SDK.
  • the first host The program list includes host program identifiers of at least some host programs supported by the entire network payment platform; resource deduction of the target card is performed to complete payment of the target card.
  • inventions of the present application provide a user terminal.
  • the user terminal has an e-commerce application, a first software development tool kit SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the user The terminal includes a calling module and an interactive module; the calling module is used to call the first SDK and use the interactive module to obtain the first host program list from the entire network payment platform when the e-commerce application triggers payment.
  • the first host program list includes the entire network The host program identification of at least some host programs supported by the payment platform; and, also used to call the target host program when the first SDK is called to determine the target host program in the first host program list; the calling module is used to pass the target
  • the host program calls the second SDK to use the interactive module to interact with the entire network payment platform, so that the entire network payment platform interacts with the host program platform to complete the payment of the target card.
  • the target card is a resource card bound to the target host program.
  • a payment management device including an interactive module.
  • the interactive module includes a sending unit; the sending unit is used to send the electronic payment to the user terminal when the e-commerce application of the user terminal triggers payment.
  • the first software development kit SDK integrated with business applications provides a first host program list.
  • the user terminal has an e-commerce application, a first SDK, a host program and a second SDK integrated with the host program.
  • the first host program list includes all The host program identifier of at least some host programs supported by the online payment platform is used to enable the user terminal to call the first SDK to determine and call up the target host program; the interaction module is used to interact with the second SDK and host called by the user terminal through the target host program.
  • the program platform interacts to complete the payment of the target card.
  • the target card is a resource card bound to the target host program.
  • embodiments of the present application provide a backend service device, including: an interaction module, configured to interact with the entire network payment platform to determine the target card for payment when the e-commerce application of the user terminal triggers payment.
  • the user terminal has an e-commerce application, a first software development kit SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program
  • the target card is a resource card bound to the target host program.
  • the target card is determined based on the interaction between the second SDK of the target host program called by the user terminal and the entire network payment platform.
  • the target host program is the host program determined in the first host program list by the user terminal calling the first SDK.
  • the first host program list It includes the host program identification of at least some host programs supported by the entire network payment platform; the execution module is used to perform the resource deduction of the target card to complete the payment of the target card.
  • embodiments of the present application provide a user terminal, including: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the payment method of the second aspect is implemented.
  • embodiments of the present application provide a payment management device, including: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the payment method of the third aspect is implemented.
  • embodiments of the present application provide a background service device, including: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the payment method of the fourth aspect is implemented.
  • embodiments of the present application provide a payment system, including the user terminal of the eighth aspect, the payment management device of the ninth aspect, and the backend service device of the tenth aspect.
  • embodiments of the present application provide a computer-readable storage medium.
  • Computer program instructions are stored on the computer-readable storage medium.
  • the following implementations are implemented as in the first aspect, the second aspect, and the third aspect.
  • Embodiments of the present application provide a payment method, user terminal, device, equipment, system and medium, wherein the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a system integrated with the host program.
  • Second SDK can interact with the entire network payment platform to obtain a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that when the first SDK determines the target host program, the user The terminal can call up the target host program.
  • the target host program can call the second SDK integrated by itself.
  • the second SDK can interact with the entire network payment platform.
  • the entire network payment platform can interact with the host program platform of the target host program to execute the target card bound to the target host program. Resources are deducted and payment is completed. E-commerce applications and different host programs in user terminals can interact with the entire network payment platform through their respective integrated SDKs, so that the entire network payment platform can interact with the host program background corresponding to different applications, making the payment process different.
  • the unified payment technical specifications among card issuing banks and other institutions realize unified management of payments and reduce the difficulty of payment management.
  • Figure 1 is a schematic architectural diagram of an example of the four-party model of users, card issuers, card organizations and acquirers provided by the embodiment of the present application;
  • FIG. 2 is a flow chart of an embodiment of the payment method provided in the first aspect of this application.
  • FIG. 3 is a flow chart of another embodiment of the payment method provided in the first aspect of this application.
  • FIG. 4 is a flow chart of another embodiment of the payment method provided in the first aspect of this application.
  • FIG. 5 is a flow chart of an embodiment of the payment method provided in the second aspect of this application.
  • FIG. 6 is a flow chart of another embodiment of the payment method provided in the second aspect of this application.
  • FIG. 7 is a flow chart of an embodiment of the payment method provided in the third aspect of this application.
  • FIG. 8 is a flow chart of another embodiment of the payment method provided in the third aspect of this application.
  • FIG. 9 is a flow chart of another embodiment of the payment method provided in the third aspect of this application.
  • Figure 10 is a flow chart of an embodiment of the payment method provided in the fourth aspect of this application.
  • FIG 11 is a flow chart of another embodiment of the payment method provided in the fourth aspect of this application.
  • Figure 12 is a flow chart of another embodiment of the payment method provided in the fourth aspect of the present application.
  • Figure 13 is a flow chart of an example of the first identification application process in the embodiment of the present application.
  • Figure 14 is a flow chart of an example of a payment process triggered by an e-commerce application in the embodiment of the present application
  • Figure 15 is a flow chart of an example of the payment code scanning payment process in the application pre-loading mode provided by the embodiment of the present application;
  • Figure 16 is a flow chart of an example of the payment code scanning payment process in the resource card front-end mode provided by the embodiment of the present application;
  • Figure 17 is a flow chart of an example of the scanning and receiving code payment process in the application pre-loading mode provided by the embodiment of the present application;
  • Figure 18 is a flow chart of an example of the scanning and receiving code payment process in the resource card front-end mode provided by the embodiment of the present application;
  • Figure 19 is a schematic structural diagram of an embodiment of a user terminal provided in the fifth aspect of this application.
  • Figure 20 is a schematic structural diagram of an embodiment of the payment management device provided in the sixth aspect of the present application.
  • Figure 21 is a schematic structural diagram of another embodiment of the payment management device provided in the sixth aspect of the present application.
  • Figure 22 is a schematic structural diagram of an embodiment of the background service device provided in the seventh aspect of the present application.
  • Figure 23 is a schematic structural diagram of an embodiment of a user terminal provided in the eighth aspect of this application.
  • each card issuer or other institution develops and provides users with applications so that users can complete electronic payments through the applications.
  • payment identifiers, technical specifications, etc. are different between different card issuers and other institutions, and the applications developed by each card issuer or other institutions are also different, making it impossible to uniformly manage payments and making it difficult to manage payments.
  • the embodiments of the present application provide a payment method, user terminal, device, equipment, system and medium, which can provide a four-party model for payment based on users, card issuers, card organizations and acquirers, so that all types of electronic payments can be made. Unified management reduces the difficulty of payment management.
  • Figure 1 is a schematic architectural diagram of an example of the four-party model of users, card issuers, card organizations and acquirers provided by the embodiment of the present application.
  • user 11 can register an account and activate and authorize the payment function in four-party mode. User 11 can also make payments through user terminal 12.
  • User terminal 12 in Figure 1 belongs to user 11. Payment methods may include payment initiated through e-commerce applications, QR code payment, etc., which are not limited here.
  • the user terminal 12 may include a mobile phone, a tablet computer, a wearable device and other terminal devices that can perform payment, and the type of the user terminal 12 is not limited here.
  • the user terminal 12 has an e-commerce application program 121 and a host program 122.
  • the e-commerce application 121 may include a merchant's application, the e-commerce application belongs to a first subject, and the first subject may include a merchant.
  • the host program 122 may include an application program of a card issuing bank.
  • the host program 122 belongs to a second subject, and the second subject may include a card issuing bank.
  • the user terminal 12 also has a first SDK 123 and a second SDK 124.
  • the first SDK 123 is integrated with the e-commerce application 121
  • the second SDK 124 is integrated with the host program 122 .
  • Each e-commerce application 121 may be integrated with a first SDK 123, and each host program 122 may be integrated with a second SDK 124.
  • the first SDK 123 and the second SDK 124 belong to a third subject, and the third subject may include the card organization 14 and the acquirer 15 .
  • the card issuing bank 13 can interface with the system of the card organization 14 through the system to authorize resource card binding and resource deduction channels, and provide users with a payment entrance through the host program 122 .
  • the system of the card issuing bank 13 can be implemented as a host program platform 16 .
  • the host program 122 is the front-end service program of the card-issuing bank 13
  • the host program platform 16 is the back-end system of the card-issuing bank 13 .
  • the host program 122 and the host program platform 16 belong to the second subject.
  • the host program platform 16 may include multiple electronic devices such as servers. The type and number of electronic devices in the host program platform 16 are not limited here.
  • the user terminal 12 can communicate and interact with the host program platform 16 through the host program 122 .
  • the card organization 14 can provide network payment services through the system, and provide the first SDK 123 and the second SDK 124 for the user terminal.
  • the acquirer 15 can receive and process online and offline payment requests.
  • the functions of the card organization 14 and the acquirer 15 can be integrated into one system.
  • the functions of the card organization 14 and the acquirer 15 can be realized through the entire network payment platform 17.
  • the first SDK 123 and the second SDK 124 are the front-end service programs of the card organization 14 and the acquirer 15
  • the entire network payment platform 17 is the back-end system of the card organization 14 and the acquirer 15 .
  • the first SDK123, the second SDK124 and the entire network payment platform 17 belong to the third entity.
  • the network-wide payment platform 17 may include multiple electronic devices such as servers.
  • the type and quantity of electronic devices in the network-wide payment platform 17 are not limited here.
  • the user terminal 12 can communicate and interact with the entire network payment platform 17 through the first SDK 123 and the second SDK 124.
  • the first aspect of this application provides a payment method that can be applied to a payment system, that is, the payment method can be executed by the payment system.
  • the payment system may include a user terminal, a network-wide payment platform, and a host program platform.
  • Figure 2 is a flow chart of an embodiment of the payment method provided in the first aspect of this application. As shown in Figure 2, the payment method may include steps S201 to S205.
  • step S201 when the e-commerce application triggers payment, the user terminal calls the first SDK to interact with the entire network payment platform to obtain the first host program list.
  • the payment triggered by the e-commerce application may include the user operating the e-commerce application in the user terminal, and the payment triggered by the e-commerce application.
  • the user terminal can utilize the ability of the first SDK to communicate and interact with the entire network payment platform, call the first SDK to interact with the entire network payment platform, and obtain the first host program list.
  • the first host program list is provided by the entire network payment platform.
  • the first host program list includes host program identifiers of at least some host programs supported by the entire network payment platform.
  • the host program supported by the entire network payment platform may include a host program authorized to the entire network payment platform.
  • the host program supported by the entire network payment platform may include a host program authorized to the entire network payment platform to activate the four-party mode payment function in the above embodiment. host program.
  • the first host program list may include host program identifiers of all host programs supported by the entire network payment platform.
  • the first host program list may include host program identifiers of some host programs supported by the entire network payment platform.
  • the number of host program identifiers of host programs in the first host program list can be purposefully reduced to improve the accuracy of pushing host programs to users and save transmission resources.
  • the user terminal can send the first payment request message to the entire network payment platform through the e-commerce application.
  • the first payment request message includes a user identification and is used to instruct the entire network payment platform to generate a first host program list based on historical payment data corresponding to the user identification and/or a pre-stored payment priority policy.
  • the network-wide payment platform obtains the priority order of the host programs supported by the network-wide payment platform based on the historical payment data corresponding to the user identification and/or the pre-stored payment priority policy, based on the priority order from high to high.
  • the host program identifiers of the first N host programs with the lowest value are retrieved, and the first host program list is generated, where N is a positive integer.
  • the first host program list includes host program identifiers of N host programs arranged from high to low priority.
  • the entire network payment platform may send a first payment feedback message to the e-commerce application of the user terminal, where the first payment feedback message includes a first host program list.
  • the user terminal receives the first payment feedback message sent by the entire network payment platform to obtain the first host program list in the first payment feedback message.
  • N is equal to the number of host programs supported by the entire network payment platform. In the case where the first host program list may include host program identifiers of some host programs supported by the entire network payment platform, N is smaller than the number of host programs supported by the entire network payment platform.
  • the user ID is used to identify the user.
  • the historical payment data corresponding to the user ID is the user's historical payment data.
  • Historical payment data is data generated by users’ previous payments.
  • Historical payment data may include the host program identification of the host program used for historical payment, the payment resource amount of the host program used for historical payment, the payment frequency of the host program used for historical payment, the payment importance of the host program used for historical payment, etc. This is not limiting.
  • the priority of the host program supported by the entire network payment platform can be determined. For example, through the historical payment data corresponding to the user ID, the host program that the user has used in historical payments can be determined, thereby generating a first host program list.
  • the host program that the user has used in historical payments has a higher priority than the host program that the user has used in historical payments.
  • the first host program list may include the host program identifiers of host programs supported by the entire network payment platform and used by users.
  • the payment priority policy can be used to determine the priority of host programs supported by the entire network payment platform.
  • the payment priority policy can be set according to scenarios, needs, etc., and is not limited here.
  • the host programs supported by the entire network payment platform can be prioritized according to the payment priority policy.
  • the payment priority policy indicates that the longer the entire network payment platform supports the host program, the higher the priority of the host program.
  • the first host program list may include the hosts of the N host programs that the entire network payment platform has supported for the longest time. Program identification.
  • the payment priority policy indicates that the higher the credibility of the host program, the higher the priority of the host program.
  • the first host program list may include the host program identifiers of the N host programs with the highest credibility on the entire network payment platform.
  • the priority of the host program supported by the entire network payment platform can be jointly determined based on the historical payment data corresponding to the user ID and the payment priority policy.
  • Payment priority policies may include policies that prioritize host programs based on historical payment data.
  • the historical payment data includes the payment frequency of the host program used by the historical payment
  • the payment priority policy indicates that the higher the payment frequency of the host program used by the historical payment, the higher the priority of the host program
  • the first host program list may include payment The host program identifiers of the N most frequent host programs.
  • the order of the host program identifiers in the first host program list reflects the priority of the host program, which can provide convenience for subsequent determination of the target host program and improve the efficiency of determining the target host program.
  • step S202 when the first SDK is called to determine the target host program in the first host program list, the user terminal calls up the target host program.
  • the target host program may be a host program determined by the user terminal according to the user's selection, or may be a host program intelligently recommended by the first SDK.
  • the target host program is a host program corresponding to a host program identifier in the first host program list.
  • the first SDK can actively call up the target host program according to the host program identifier assigned to the target host program by the entire network payment platform, that is, trigger the start of the target host program.
  • the encrypted order information can also be transmitted to the target host program, so that the target host program can transmit the order information to the second SDK.
  • the user terminal can call the first SDK to directly display the first host program list, and determine the host program corresponding to the selected host program identifier in the first host program list as the target host program according to the user's selection input. .
  • the user terminal may call the first SDK to determine the host program with the highest priority corresponding to the host program identifier in the first host program list as the target host program.
  • the user terminal can call the first SDK to obtain the second host program list locally (that is, the user terminal local); call the first SDK to obtain the intersection of the first host program list and the second host program list, and display the intersection; respond Based on the user's first input, the host program corresponding to the host program identifier indicated by the first input in the intersection is determined as the target host program.
  • the second host program list includes host program identifiers of host programs owned by the user terminal.
  • the host program supported by the entire network payment platform may be different from the host program owned by the user terminal.
  • the user terminal may not have some of the host programs supported by the entire network payment platform corresponding to the host program identification in the first host program list, and the user terminal cannot adjust the host program. Start a host program that it does not own.
  • the intersection of the first host program list and the second host program list may be obtained.
  • the intersection includes the host program identifier of the host program supported by the entire network payment platform and owned by the user terminal.
  • the target host program selected by the user in the intersection can be called up by the user terminal.
  • the user terminal can call the first SDK to obtain the second host program list locally; call the first SDK to obtain the intersection of the first host program list and the second host program list, and assign the priority corresponding to the host program identifier in the intersection
  • the highest host program is determined as the target host program.
  • the user terminal calls the first SDK to automatically determine the target host program and activate the target host program, which can quickly and accurately provide users with the host program for payment, providing users with faster and more convenient payment services.
  • step S203 the user terminal calls the second SDK through the target host program to interact with the entire network payment platform.
  • step S204 the entire network payment platform interacts with the host program platform.
  • step S205 the host program platform performs resource deduction of the target card to complete the payment of the target card.
  • the target card is a resource card bound to the target host program.
  • the second SDK can be called through the target host program.
  • the second SDK called here is the second SDK integrated with the target host program.
  • the second SDK interacts with the entire network payment platform, and the entire network payment platform interacts with the host program platform.
  • the host program platform determines the target card and performs resource deduction on the target card to complete the payment of the target card.
  • the host program platform that interacts with the entire network payment platform is the host program platform corresponding to the target host program.
  • the target card is a resource card bound to the target host program.
  • the target card can be the default resource card used for payment by the target host program, or it can be a resource card selected by the user among the resource cards bound to the target host program.
  • the target card can be switched according to the user's needs and is not limited here.
  • the confirmation of the target card can be determined based on the interaction between the second SDK and the entire network payment platform, and the interaction between the entire network payment platform and the host program platform.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the first SDK can interact with the entire network payment platform to obtain a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that when the first SDK determines the target host program, the user The terminal can call up the target host program.
  • the target host program can call the second SDK integrated by itself.
  • the second SDK can interact with the entire network payment platform.
  • the entire network payment platform can interact with the host program platform of the target host program to execute the target card bound to the target host program. Resources are deducted and payment is completed.
  • E-commerce applications and different host programs in user terminals can interact with the entire network payment platform through their respective integrated SDKs, so that the entire network payment platform can interact with the host program background corresponding to different applications, making the payment process different.
  • the unified payment technical specifications and unified payment identifiers among card issuing banks and other institutions realize unified management of payments and reduce the difficulty of payment management.
  • the host program platforms corresponding to different host programs share the same network-wide payment platform, and by providing a unified SDK for different host programs and e-commerce applications, payment capabilities are given to different host programs and e-commerce applications, making different hosts Programs and e-commerce applications share the same network-wide payment platform through their respective integrated SDKs, and share online and offline payment acceptance networks and industry content.
  • Payment management is no longer subject to the host program of the card issuer or other institution to which the payment account belongs. restrictions, improve operational efficiency, reduce operating costs and construction costs, and expand the scope of payment acceptance. And users do not need to use different operating methods for different host program payments, and the user's payment experience is unified, which improves the user's payment experience.
  • the user terminal can also interact with the entire network payment platform to obtain the order message corresponding to the payment to facilitate subsequent payment initiation.
  • the user terminal initiates an order request to the entire network payment platform through the e-commerce application.
  • the order request is used to request order information from the entire network payment platform.
  • the network-wide payment platform can provide order information to the e-commerce application.
  • Order information may include order number, order amount, order details and other information, which is not limited here.
  • the e-commerce application of the user terminal receives the order information and can display the order page according to the order information.
  • the order page includes order information.
  • the user terminal triggers payment.
  • the third input is the user's payment triggering input.
  • the user terminal may trigger step S201.
  • a first identifier can be assigned to a host program that has the function of making payments using the entire network payment platform, so that during the payment process, the first identifier can be used to determine whether the current payment can adopt the payment method in the embodiment of the present application. method to proceed.
  • Figure 3 is a flow chart of another embodiment of the payment method provided in the first aspect of this application. The difference between Figure 3 and Figure 2 is that step S203 in Figure 2 can be specifically refined into steps S2031 to step S2033 in Figure 3, and step S204 in Figure 2 can be specifically refined into steps S2041 and S2041 in Figure 3. Step S2042, step S205 in Figure 2 can be specifically refined into step S2051 and step S2052 in Figure 3, and the payment method in Figure 3 can also include step S206 and step S207.
  • step S2031 the user terminal calls the second SDK to query whether the target host program has a corresponding first identifier.
  • the first identifier is used to indicate that the user account in the host program has the function of making payments using the entire network payment platform.
  • the first identifier can also represent the binding relationship between the user account in the host program and the entire network payment platform.
  • the first identifier can be assigned by the entire network payment platform to the user account in the host program.
  • the same user can have different first identities in different host programs. Different users have different first identities in the same host program.
  • the first identifier can be implemented as a string, a serial number, etc., which is not limited here.
  • the first identification may have a validity period. During the validity period, the first identification is valid. If the validity period is exceeded, the first identification is invalid and a new first identification needs to be applied.
  • the validity period can be a fixed length of time, or it can be related to the login status of the user account. It can be set according to the scenario, needs, etc., and is not limited here.
  • the user terminal will obtain the first identifier and store the first identifier locally in the user terminal.
  • the user terminal can call the second SDK to locally query whether the target host program has the corresponding first identifier.
  • the network-wide payment platform will store the first identifier.
  • the user terminal can call the second SDK to initiate a query request to the network-wide payment platform, and the network-wide payment platform queries whether the target host program has the corresponding first identifier.
  • step S2032 if the target host program has a corresponding first identifier, the user terminal calls the second SDK to send the first payment message to the entire network payment platform.
  • the target host program has a corresponding first identifier, indicating that the user account in the target host program has the function of making payments using the entire network payment platform and can continue the payment process.
  • the user terminal calls the second SDK to send the first payment message to the entire network payment platform.
  • the first payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • step S2041 the entire network payment platform sends the first payment message to the host program platform.
  • the network-wide payment platform determines, based on the first identifier corresponding to the target host program, that the user account in the target host program has the function of making payments using the network-wide payment platform, and can determine the target host program based on the host program identifier of the target host program, thereby determining the target
  • the host program platform of the host program sends the first payment message to the host program platform of the target host program.
  • step S2051 the host program platform determines the target card according to the first payment message, and performs resource deduction on the target card to complete the payment of the target card.
  • the first payment message may include card information.
  • the card information in the first payment message may indicate the target card.
  • the host program platform of the target host program can determine the target card according to the first payment message, and perform resource deduction of the target card to complete the payment of the target card.
  • step S206 when the target host program does not have a corresponding first identifier, the user terminal calls the target host program to request the first identifier corresponding to the target host program from the network-wide payment platform through the host program platform.
  • the target host program does not have a corresponding first identifier, which means that the user account in the target host program does not have the function of making payments using the entire network payment platform or the original first identifier of the target host program has expired.
  • the user terminal needs to request the first identifier corresponding to the target host program from the entire network payment platform.
  • the whole network payment platform will assign the first identification to the target host program and provide the first identification to the target host program through the host program platform, that is, the user account in the host program of the user terminal device is authorized to make payment using the whole network payment platform. Function.
  • the user terminal when logging in to the target host program, the user terminal calls the target host program to send a first identification request message to the host program platform.
  • the first identification request message includes user identity information.
  • User identity information includes information related to the user's identity, which may include the user's name, user's ID number, user's mobile phone number, user's resource card number, etc. To ensure data security, user identity information may be encrypted information.
  • the host program platform In response to the first identification request message, the host program platform sends a second identification request message to the entire network payment platform.
  • the second identification request message is used to request the first identification.
  • the second identification request message includes user identity information and host program identification.
  • the host program identifier here is specifically the host program identifier of the target host program.
  • the second identification request message may also include the user account of the user in the target host program.
  • step S207 the entire network payment platform provides the first identifier to the target host program through the host program platform.
  • the entire network payment platform responds to the second identification request message and provides the first identification to the target host program.
  • the All-Network Payment Platform may not allocate the first identifier to the user's user account at the card issuing bank or other institution, but instead When the user uses the host program of the card issuing bank or other institution to make payment, the first identifier is assigned to the user account in the host program.
  • the network-wide payment platform can assign a first identity to the target host program based on the user identity information, the host program identity and the pre-stored subscribed user identity information.
  • the identity information of activated users pre-stored by the entire network payment platform includes the identity information of users who have activated the function of making payments using the entire network payment platform.
  • the network-wide payment platform After assigning the first identification to the target host program, the network-wide payment platform sends a second identification feedback message to the host program platform.
  • the second identity feedback message includes the assigned first identity.
  • the host program platform may send the first identification feedback message to the target host program in the user terminal according to the second identification feedback message.
  • the first identification feedback message may include the first identification.
  • the entire network payment platform can match user identity information and subscribed user identity information, and assign the first identifier based on the matching result of user identity information and subscribed user identity information. If the user identity information matches the user identity information that has been activated, the entire network payment platform can assign a first identifier. In addition, depending on the specific matching of the user identity information, determine whether it is necessary to compare the user account corresponding to the user identity information in the target host program with the full network payment platform. The user account corresponding to the user identity information in the online payment platform has been bound.
  • the All-Network Payment Platform needs to create a user account corresponding to the user's identity information in the All-Network Payment Platform.
  • the user identity information includes a first user unique identifier and a first phone number
  • the subscribed user identity information includes a second user unique identifier and a second phone number.
  • the first user unique identifier is the user unique identifier in the user identity information.
  • the second user unique identifier is the user unique identifier in the subscribed user identity information.
  • the user's unique identifier is used to identify the user and is unique. Different users have different user unique identifiers.
  • the user's unique identifier may include an ID number, which is not limited here.
  • the first phone number is the phone number of the user in the user identity information
  • the second phone number is the phone number of the user in the subscribed user identity information.
  • the network-wide payment platform binds the first user account and the second user account and generates the first identification.
  • the target second user's unique identifier is a second user's unique identifier that is consistent with the first user's unique identifier.
  • the user has only one user account in the entire network payment platform, and the user has different user accounts in different host programs.
  • the first user account is the user account in the target host program corresponding to the first user's unique identifier, that is, the first user account is the user account in the target host program of the user represented by the first user's unique identifier.
  • the second user account is the user account corresponding to the target second user's unique identifier and the target second phone number in the entire network payment platform.
  • the target second phone number is a second phone number that is consistent with the first phone number. That is, the second user account can be regarded as the user account in the entire network payment platform represented by the unique identifier of the target second user and the target second phone number.
  • the identity information of activated users includes the identity information of users who have activated the function of making payments using the entire network payment platform.
  • the identity information of the activated user includes the unique identifier of the target second user, indicating that the user represented by the unique identifier of the first user has activated the function of payment using the entire network payment platform.
  • the user has a user account of the entire network payment platform, and the first user account is Bind to the second user account.
  • the subscribed user identity information only has one piece of information including the unique identifier of the target second user, regardless of whether the subscribed user identity information includes a second phone number that is consistent with the first phone number, the first user account and The second user account binding is to bind the user's user account in the target host program with the user's user account in the entire network payment platform, and generate a first identification.
  • the second user is selected based on the two or more pieces of information.
  • the user account in the entire network payment platform whose unique identifier is consistent with the first user's unique identifier, and whose second phone number is consistent with the first phone number, shall be regarded as the second user account. Bind the first user account and the second user account, and generate the first identification.
  • the entire network payment platform creates a new third user account, binds the first user account and the third user account, and generates the first identification.
  • the third user account is the user account corresponding to the first user's unique identifier in the entire network payment platform.
  • the identity information of the activated user does not include the unique identifier of the target second user, which means that there is no user account corresponding to the unique identifier of the first user in the user accounts of the entire network payment platform.
  • a user account of the user represented by the first user's unique identifier in the entire network payment platform that is, a third user account
  • the first user account and the third user account can be bound, and the first identifier can be generated.
  • the subscribed user identity information does not include the unique identifier of the target second user, but includes a second phone number that is consistent with the first phone number, and has a user account corresponding to the second phone number on the entire network payment platform.
  • the second phone number has been real-named, based on payment security considerations such as whether the first phone number is incorrect, the first user account will not be bound to the user account corresponding to the second phone number in the entire network payment platform. .
  • real-name verification can be carried out through the operator of the second phone number.
  • the user account corresponding to the number has not been bound to the first user account.
  • the first user account can be bound to the user account corresponding to the second phone number in the entire network payment platform, and the first identification can be generated.
  • step S2033 the user terminal calls the second SDK to send the second payment message to the entire network payment platform.
  • the second payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the first identifier corresponding to the target host program is the first identifier assigned by the entire network payment platform in step S207.
  • step S2042 the entire network payment platform sends the second payment message to the host program platform.
  • step S2052 the host program platform determines the target card according to the second payment message, and performs resource deduction of the target card to complete payment of the target card.
  • step S2033 For the specific content of step S2033, step S2042 and step S2052, please refer to the relevant content of step S2032, step S2041 and step S2051, which will not be described again here.
  • step S2032 and step S2033 before step S2032 and step S2033, the version of the second SDK, the login status of the second SDK, and/or the user account in the target host program, the security of the resource transfer account, etc. can be detected. , if the detection passes, execute step S2032 and step S2033 again to ensure the security and reliability of payment.
  • the detection of the version of the second SDK may include the following steps a1 and a2.
  • the user terminal calls the second SDK of the target host program to send a version determination message to the entire network payment platform.
  • the version determination message may include version information of the second SDK of the target host program.
  • the version information of the second SDK represents the version of the second SDK.
  • the entire network payment platform determines whether the version of the second SDK is an available version based on the version determination message, and sends a version feedback message to the second SDK of the target host program.
  • the network-wide payment platform can obtain the version information of the second SDK from the version determination message, and determine whether the version represented by the version information of the second SDK is an available version of the network-wide payment platform.
  • the entire network payment platform uses a version feedback message to feedback to the second SDK of the user terminal whether the version of the second SDK is an available version.
  • the version feedback message indicates whether the version of the second SDK is an available version.
  • the available versions of the entire network payment platform include version 1.20, version 1.21 and version 1.22, and the version information of the second SDK in the version determination message represents version 1.05, then the version feedback message sent by the entire network payment platform represents that the version of the second SDK is not Available versions.
  • step S2032 and S2033 are not performed, and the user terminal may prompt the user to upgrade the second SDK. If only the version of the second SDK is detected, the version feedback message indicates that the version of the second SDK is an available version, and steps S2032 and S2033 can be performed. If in addition to detecting the version of the second SDK, other tests need to be performed, and if the version feedback message indicates that the version of the second SDK is an available version, it can be determined whether to perform steps S2032 and S2033 based on the results of other tests. .
  • the detection of the login status of the second SDK may include the following steps b1 and b2.
  • the user terminal calls the second SDK of the target host program to send an SDK login determination message to the entire network payment platform.
  • the SDK login determination message may include information used to identify the second SDK of the target host program.
  • the SDK login determination message may include the SDK identification of the second SDK or the host program identification of the target host program.
  • the entire network payment platform determines whether the second SDK is logged in based on the SDK login determination message, and sends an SDK login feedback message to the second SDK of the target host program.
  • the entire network payment platform can determine whether the second SDK is logged in based on the information in the SDK login determination message.
  • the entire network payment platform can feedback to the second SDK of the user terminal whether the second SDK is logged in through the SDK login feedback message.
  • the SDK login feedback message can indicate whether the second SDK is logged in. If the SDK login feedback message indicates that the second SDK has not been logged in, steps S2032 and S2033 are not performed, and the user terminal may prompt the user to log in to the second SDK. If only the login status of the second SDK is detected and the SDK login feedback message indicates that the second SDK has been logged in, steps S2032 and S2033 may be performed.
  • Detecting the security of user accounts and resource transfer accounts in the target host program may include the following steps c1 and c2.
  • the user terminal calls the second SDK of the target host program to send a security determination message to the entire network payment platform.
  • the security determination message may include the user account in the target host program and the resource transfer account for this payment.
  • the entire network payment platform determines whether the user account in the target host program and the account to which resources are transferred for this payment are safe based on the security determination message, and sends a security feedback message to the second SDK of the target host program.
  • the entire network payment platform searches for the historical payment data and other related data of the user account in the target host program. It can also search for the historical payment data and other related data of the account to which the resources for this payment are transferred. According to the target host program The historical payment data and other related data of the user account in the system and the security determination policy preset by the entire network payment platform determine whether the user account in the target host program is safe, and the historical payment data of the account transferred according to the resources of this payment and Other relevant data and the security determination strategy preset by the entire network payment platform determine whether the resources transferred to the account for this payment are safe. The entire network payment platform uses a security feedback message to feedback to the second SDK of the user terminal whether the user account and resource transfer account in the target host program are safe.
  • the security feedback message indicates whether the user account and resource transfer account in the target host program are safe. If the security feedback message indicates that the user account and resource transfer account in the target host program are unsafe, steps S2032 and S2033 are not executed, and the user terminal may prompt the user to suspend payment or perform security verification. If only the security of the user account and resource transfer account in the target host program is tested, and the security feedback message indicates that the user account and resource transfer account in the target host program are safe, steps S2032 and S2033 may be performed. If in addition to testing the security of the user account and resource transfer account in the target host program, other tests need to be performed. When the security feedback message indicates that the user account and resource transfer account in the target host program are safe, Whether to execute step S2032 and step S2033 can be determined based on the results of other detections.
  • the entire network payment platform tests the security of user accounts and resource transfer accounts, allowing each host program to share security detection strategies, which can improve the overall security monitoring and processing level of the payment industry and better provide protection for payment security.
  • Figure 4 is a flow chart of yet another embodiment of the payment method provided in the first aspect of this application. The difference between Figure 4 and Figure 2 is that the payment method shown in Figure 4 may also include step S208 and step S209.
  • step S208 when the user applies for a resource card, the host program platform sends the user identity information to the entire network payment platform.
  • the user's identity information When a user applies for a resource card, the user's identity information will be retained in the host program platform to which the resource card belongs.
  • the host program platform will send user identity information to the entire network payment platform.
  • user identity information For the specific content of the user identity information, please refer to the relevant descriptions in the above embodiments and will not be described again here.
  • step S209 the entire network payment platform stores the user identity information as activated user identity information.
  • the whole network payment platform stores the user identity information as the activated user identity information, so that when the subsequent terminal device applies for the first identification to the whole network payment platform, the activated user identity information can be used to provide the first identification for the user's host program.
  • the activated user identity information can be used to provide the first identification for the user's host program.
  • the function of making payments on a universal network-wide payment platform is available to users upon opening the card, which can reduce the user's operations to activate the payment function, simplify the process of activating the payment function, and improve the efficiency of function activation and user experience.
  • the user terminal can also make payment based on the payment code and collection code.
  • the user terminal can call the second SDK to initiate a payment code request to the entire network payment platform.
  • the entire network payment platform issues the payment code to the second SDK.
  • the user terminal can call the second SDK to display the payment code, so that the payment code is scanned by the payment acceptance terminal.
  • the payment acceptance terminal scans the payment code and initiates a payment request to the entire network payment platform.
  • the entire network payment platform receives the payment request initiated by the payment acceptance terminal by scanning the payment code, and interacts with the host program platform to complete the payment indicated by the payment request.
  • the payment acceptance terminal may include point of sales (POS) equipment, etc., and is not limited here.
  • the user terminal calls the second SDK to request and display the payment code, so that the payment code scanned by the payment acceptance terminal can be uniformly managed by the entire network payment platform.
  • the user terminal scans the collection code for payment
  • the user terminal calls the second SDK to scan the collection code and initiates a payment request to the entire network payment platform.
  • the entire network payment platform interacts with the host program platform to complete the payment indicated by the payment request.
  • the scanning function of the user terminal is the scanning function managed by the second SDK, so that the payment by scanning the collection code can be uniformly managed by the entire network payment platform.
  • the second aspect of this application provides a payment method, which is applied to a user terminal, that is, the payment method can be executed by the user terminal.
  • the payment method may include steps S301 to S303.
  • step S301 when the e-commerce application triggers payment, the first SDK is called to obtain the first host program list from the entire network payment platform.
  • the user terminal may send the first payment request message to the entire network payment platform through the e-commerce application.
  • the first payment request message includes a user identification and is used to instruct the entire network payment platform to generate a first host program list based on historical payment data corresponding to the user identification and/or a pre-stored payment priority policy.
  • the first host program list includes host program identifiers of N host programs arranged from high to low priority, where N is a positive integer.
  • the user terminal receives the first payment feedback message sent by the entire network payment platform.
  • the first payment feedback message includes the first host program list.
  • step S302 when the first SDK is called to determine the target host program in the first host program list, the target host program is called.
  • the user terminal before calling up the target host program, can call the first SDK to obtain the second host program list locally; call the first SDK to obtain the intersection of the first host program list and the second host program list, and display the intersection ; In response to the user's first input, determine the host program corresponding to the host program identification indicated by the first input in the intersection as the target host program.
  • the second host program list includes host program identifiers of host programs owned by the user terminal.
  • the user terminal before calling up the target host program, can call the first SDK to obtain the second host program list locally, call the first SDK to obtain the intersection of the first host program list and the second host program list, and The host program with the highest priority corresponding to the host program identifier in the intersection is determined as the target host program.
  • the second host program list includes host program identifiers of host programs owned by the user terminal.
  • step S303 the target host program calls the second SDK to interact with the entire network payment platform, so that the entire network payment platform interacts with the host program platform to complete payment of the target card.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the first SDK can interact with the entire network payment platform to obtain a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that when the first SDK determines the target host program, the user The terminal can call up the target host program.
  • the target host program can call the second SDK integrated by itself.
  • the second SDK can interact with the entire network payment platform.
  • the entire network payment platform can interact with the host program platform of the target host program to execute the target card bound to the target host program. Resources are deducted and payment is completed.
  • E-commerce applications and different host programs in user terminals can interact with the entire network payment platform through their respective integrated SDKs, so that the entire network payment platform can interact with the host program background corresponding to different applications, making the payment process different.
  • the unified payment technical specifications among card issuing banks and other institutions realize unified management of payments and reduce the difficulty of payment management.
  • the host program platforms corresponding to different host programs share the same network-wide payment platform. Different host programs share the same network-wide payment platform through their respective integrated SDKs. Payment management is no longer restricted by the host program of the card issuer or other institution to which the payment account belongs. , the user payment experience is unified, and users do not need to use different operating methods for different host program payments, which improves the user's payment experience.
  • the user terminal before step S301, can also interact with the entire network payment platform to obtain the order message corresponding to the payment, so as to facilitate subsequent payment initiation.
  • the user terminal can obtain order information from the entire network payment platform through the e-commerce application in response to the user's second input; and trigger payment in response to the user's third input on the order page.
  • the order page includes order information.
  • the user terminal can also interact with the entire network payment platform.
  • a first identifier can be assigned to a host program that has the function of making payments using the entire network payment platform, so that during the payment process, it can be determined whether the current payment can be made using the payment method in the embodiment of the present application.
  • Figure 6 is a flow chart of another embodiment of the payment method provided in the second aspect of this application. The difference between Figure 6 and Figure 5 is that step S303 in Figure 5 can be specifically detailed into steps S3031 to step S3035 in Figure 6 .
  • step S3031 the second SDK is called to query whether the target host program has a corresponding first identifier.
  • step S3032 when the target host program has a corresponding first identifier, the second SDK is called to send the first payment message to the entire network payment platform, so that the entire network payment platform sends the first payment message to the host program platform, The host program platform performs the resource deduction of the target card and completes the payment of the target card.
  • the first payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • step S3033 if the target host program does not have a corresponding first identifier, the target host program is called to request the first identifier corresponding to the target host program from the network-wide payment platform through the host program platform.
  • the user terminal when logging into the target host program, the user terminal calls the target host program to send a first identification request message to the host program platform; the user terminal calls the target host program to receive the first identification feedback message sent by the host program platform.
  • the first identification request message includes user identity information and is used to instruct the host program platform to send the second identification request message to the entire network payment platform.
  • the second identification request message is used to request the first identification.
  • the second identification request message includes user identity information and host program identification.
  • the first identification feedback message includes the first identification.
  • the first identification feedback information is generated based on the second identification feedback message sent by the entire network payment platform to the host program platform.
  • the second identification feedback message includes the first identification.
  • the first identification is obtained by the entire network payment platform based on user identity information, host program identification and pre-stored user identity information.
  • step S3034 the target host program is called to receive the first identifier corresponding to the target host program distributed by the entire network payment platform through the host program platform.
  • step S3035 the second SDK is called to send the second payment message to the entire network payment platform, so that the entire network payment platform sends the second payment message to the host program platform, and the host program platform performs the resource deduction of the target card to complete the target card payment.
  • the second payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the version of the second SDK, the login status of the second SDK, and/or the user account in the target host program, the security of the resource transfer account, etc. can be detected. .
  • the user terminal can call the second SDK of the target host program to send a version determination message to the entire network payment platform; receive the version determination message sent by the entire network payment platform through the second SDK of the target host program. Version feedback message.
  • the version determination message instructs the entire network payment platform to determine whether the version of the second SDK is an available version.
  • the version feedback message indicates whether the version of the second SDK is an available version.
  • the user terminal can call the second SDK of the target host program to send the SDK login determination message to the entire network payment platform; receive the entire network payment platform through the second SDK of the target host program SDK login feedback message sent.
  • the SDK login determination message instructs the entire network payment platform to determine whether the second SDK is logged in.
  • the SDK login feedback message indicates whether the second SDK version is logged in.
  • the user terminal can call the second SDK of the target host program to send a security determination message to the entire network payment platform; through the target host program's The second SDK receives security feedback messages sent by the entire network payment platform.
  • the security determination message instructs the entire network payment platform to determine whether the user account in the target host program and the account to which the resources for this payment are transferred are safe.
  • the security feedback message indicates whether the user account and resource transfer account in the target host program are safe.
  • the subscribed user identity information includes the user identity information sent by the host program platform to the entire network payment platform when the user applies for a resource card.
  • the host program platform sends the user identity information to the entire network payment platform when the user applies for a resource card.
  • the user terminal can also make payment based on the payment code.
  • the user terminal can call the second SDK to obtain the payment code from the entire network payment platform.
  • the payment code is used to be scanned by the payment acceptance terminal to initiate a payment request to the entire network payment platform.
  • the specific content of payment by the user terminal according to the payment code can be found in the relevant descriptions in the above embodiments, and will not be described again here.
  • the user terminal can also make payment based on the collection code.
  • the user terminal can call the second SDK to scan the collection code and initiate a payment request to the entire network payment platform.
  • the specific content of payment by the user terminal according to the collection code can be found in the relevant descriptions in the above embodiments, and will not be described again here.
  • the third aspect of this application provides a payment method that is applied to the entire network payment platform, that is, the payment method can be executed by the entire network payment platform.
  • the specific content of the entire network payment platform can be found in the relevant descriptions in the above embodiments and will not be described again here.
  • Figure 7 is a flow chart of an embodiment of the payment method provided in the third aspect of this application. As shown in Figure 7, the payment method may include step S401 and step S402.
  • step S401 when the e-commerce application of the user terminal triggers payment, a first host program list is provided to the first SDK integrated with the e-commerce application in the user terminal.
  • the first host program list includes host program identifiers of at least some host programs supported by the entire network payment platform, and is used to enable the user terminal to call the first SDK to determine and call up the target host program.
  • the entire network payment platform can receive a first payment request message sent by a user terminal through an e-commerce application.
  • the first payment request message includes a user identification; historical payment data corresponding to the user identification and/or pre-stored payment priorities. level strategy, obtain the priority order of host programs supported by the entire network payment platform; generate a first host program list based on the host program identifiers of the top N host programs from high to low priority, N is a positive integer; provide the user with The e-commerce application of the terminal sends the first payment feedback message.
  • the first payment feedback message includes the first host program list.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program corresponding to the host program identifier specified by the user in the intersection of the first host program list and the second host program list.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program with the highest priority corresponding to the host program identifier in the intersection of the first host program list and the second host program list.
  • step S402 interact with the second SDK and host program platform called by the user terminal through the target host program to complete payment with the target card.
  • the target card is a resource card bound to the target host program.
  • step S401 and step S402 please refer to the relevant descriptions in the above embodiments and will not be described again here.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the entire network payment platform can interact with the first SDK and provide the first SDK with a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that the first SDK determines the target host program.
  • the user terminal can call up the target host program.
  • the network-wide payment platform can interact with the second SDK integrated with the target host program itself, and can also interact with the host program platform of the target host program, allowing the host program platform to perform resource deductions on the target card bound to the target host program to complete the payment.
  • the entire network payment platform can interact with e-commerce applications in user terminals and SDKs integrated with different host programs. It can also interact with the host program background corresponding to different applications to enable payments between different card issuers and other institutions during the payment process.
  • the unified technical specifications realize unified management of payments and reduce the difficulty of payment management.
  • the host program platforms corresponding to different host programs share the same network-wide payment platform. Different host programs share the same network-wide payment platform through their respective integrated SDKs. Payment management is no longer restricted by the host program of the card issuer or other institution to which the payment account belongs. , the user payment experience is unified, and users do not need to use different operating methods for different host program payments, which improves the user's payment experience.
  • the network-wide payment platform can also interact with the user terminal to provide order messages corresponding to the payment to facilitate subsequent payment initiation.
  • the network-wide payment platform responds to the order request of the e-commerce application and provides order information to the e-commerce application.
  • the network-wide payment platform can also interact with the user terminal to provide order messages.
  • a first identifier can be assigned to a host program that has the function of making payments using the entire network payment platform, so that during the payment process, it can be determined whether the current payment can be made using the payment method in the embodiment of the present application.
  • Figure 8 is a flow chart of another embodiment of the payment method provided in the third aspect of this application. The difference between Figure 8 and Figure 7 is that step S402 in Figure 7 can be specifically detailed into steps S4021 to S4025 in Figure 8 .
  • step S4021 when the user terminal calls the second SDK to determine that the target host program has a corresponding first identifier, the first payment message sent by the user terminal calling the second SDK is received.
  • the first identifier is used to indicate that the user account in the host program has the function of making payments using the entire network payment platform.
  • step S4022 send the first payment message to the host program platform.
  • the first payment message instructs the host program platform to perform resource deduction of the target card and complete the payment of the target card.
  • the first payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • step S4023 when the user terminal calls the second SDK and determines that the target host program does not have a corresponding first identifier, the first identifier is provided to the target host program through the host program platform.
  • the entire network payment platform when logging in to the target host program, receives the second identity request message sent by the host program platform; based on the user identity information, the host program identity and the pre-stored user identity information, the target host The program assigns a first identification; sends a second identification feedback message to the host program platform, so that the host program platform sends the first identification feedback message to the target host program according to the second identification feedback message.
  • the second identification request message includes user identity information and host program identification.
  • the second identification request message is generated according to the first identification request message sent by the terminal device by calling the target host program.
  • the first identification request message includes user identity information.
  • the first identification feedback message and the second identification feedback message include the first identification.
  • the user identity information includes a first user unique identifier and a first phone number.
  • the subscribed user identity information includes a second user unique identifier and a second phone number.
  • the network-wide payment platform binds the first user account and the second user account and generates the first identification.
  • the target second user's unique identifier is a second user's unique identifier that is consistent with the first user's unique identifier.
  • the first user account is the user account corresponding to the first user's unique identifier in the target host program.
  • the second user account is the user account corresponding to the target second user's unique identifier and the target second phone number in the entire network payment platform.
  • the target second phone number is a second phone number that is consistent with the first phone number.
  • the entire network payment platform can create a new third user account, bind the first user account and the third user account, and generate the first identification.
  • the third user account is the user account corresponding to the first user's unique identifier in the entire network payment platform.
  • step S4024 the second payment message sent by the user terminal calling the second SDK is received.
  • step S4025 a second payment message is sent to the host program platform.
  • the second payment message instructs the host program platform to perform resource deduction of the target card and complete the payment of the target card.
  • the second payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the version of the second SDK, the login status of the second SDK, and/or the user account in the target host program, the security of the resource transfer account, etc. may be detected.
  • the entire network payment platform can receive a version determination message sent by the second SDK that the user terminal calls the target host program; and determine whether the version of the second SDK is an available version based on the version determination message. ;Send a version feedback message to the second SDK of the target host program.
  • the version feedback message indicates whether the version of the second SDK is an available version.
  • the entire network payment platform can receive the SDK login determination message sent by the second SDK that the user terminal calls the target host program; determine whether the second SDK is logged in based on the SDK login determination message; Send an SDK login feedback message to the second SDK of the target host program.
  • the SDK login feedback message indicates whether the second SDK is logged in.
  • the entire network payment platform can receive the security determination message sent by the user terminal calling the second SDK of the target host program; according to the security determination message Determine whether the user account in the target host program and the account to which the resources for this payment are transferred are safe; send a security feedback message to the second SDK of the target host program.
  • the security feedback message indicates whether the user account and resource transfer account in the target host program are safe.
  • Figure 9 is a flow chart of another embodiment of the payment method provided in the third aspect of this application. The difference between Figure 9 and Figure 7 is that the payment method shown in Figure 9 may also include step S403 and step S404.
  • step S403 when the user applies for a resource card, the user identity information sent by the host program platform is received.
  • step S404 the user identity information is stored as subscribed user identity information.
  • step S403 and step S404 please refer to the relevant descriptions in the above embodiments and will not be described again here.
  • the user terminal can also make payment based on the payment code.
  • the entire network payment platform can respond to the payment code request from the user terminal calling the second SDK and issue the payment code to the second SDK; receive the payment request initiated by the payment acceptance terminal by scanning the payment code, and interact with the host program platform to complete the payment request instructions payment.
  • the specific content of payment by the user terminal according to the payment code can be found in the relevant descriptions in the above embodiments, and will not be described again here.
  • the user terminal can also make payment based on the collection code.
  • the entire network payment platform can receive the payment request initiated by the user terminal by calling the second SDK to scan the collection code; interact with the host program platform to complete the payment indicated by the payment request.
  • the specific content of payment by the user terminal according to the collection code can be found in the relevant descriptions in the above embodiments, and will not be described again here.
  • the fourth aspect of this application also provides a payment method, which is applied to the host program platform, that is, the payment method can be executed by the host program platform.
  • the payment method may include step S501 and step S502.
  • step S501 when the e-commerce application of the user terminal triggers payment, it interacts with the entire network payment platform to determine the target card used for payment.
  • the target card is a resource card bound to the target host program.
  • the target card is determined based on the interaction between the second SDK of the target host program called by the user terminal and the entire network payment platform.
  • the target host program is the user terminal that calls the host program determined by the first SDK in the first host program list.
  • the first host program list includes host program identifiers of at least some host programs supported by the entire network payment platform.
  • the first host program list includes host program identifiers of N host programs arranged from high to low priority, where N is an integer.
  • the priority is determined based on the historical payment data corresponding to the user identification provided by the user terminal through the e-commerce application and/or the pre-stored payment priority policy.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program corresponding to the host program identifier specified by the user in the intersection of the first host program list and the second host program list.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program with the highest priority corresponding to the host program identifier in the intersection of the first host program list and the second host program list.
  • step S502 resource deduction of the target card is performed to complete the payment of the target card.
  • step S501 and step S502 please refer to the relevant descriptions in the above-mentioned embodiments, and will not be described again here.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the entire network payment platform can interact with the first SDK and provide the first SDK with a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that the first SDK determines the target host program.
  • the user terminal can call up the target host program.
  • the network-wide payment platform can interact with the second SDK integrated with the target host program itself, and can also interact with the host program platform of the target host program, allowing the host program platform to perform resource deductions on the target card bound to the target host program to complete the payment.
  • the entire network payment platform can interact with e-commerce applications in user terminals and SDKs integrated with different host programs. It can also interact with the host program background corresponding to different applications to enable payments between different card issuers and other institutions during the payment process.
  • the unified technical specifications realize unified management of payments and reduce the difficulty of payment management.
  • the host program platforms corresponding to different host programs share the same network-wide payment platform. Different host programs share the same network-wide payment platform through their respective integrated SDKs. Payment management is no longer restricted by the host program of the card issuer or other institution to which the payment account belongs. , the user payment experience is unified, and users do not need to use different operating methods for different host program payments, which improves the user's payment experience.
  • a first identifier can be assigned to a host program that has the function of making payments using the entire network payment platform, so that during the payment process, it can be determined whether the current payment can be made using the payment method in the embodiment of the present application.
  • Figure 11 is a flow chart of another embodiment of the payment method provided in the fourth aspect of this application. The difference between Figure 11 and Figure 10 is that step S501 in Figure 10 can be specifically detailed into steps S5011 to step S5014 in Figure 11 .
  • step S5011 when the user terminal calls the second SDK to determine that the target host program has a corresponding first identifier, the first payment message sent by the user terminal through the network-wide payment platform by calling the second SDK is received.
  • the first payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • step S5012 the target card is determined according to the first payment message.
  • step S5013 when the user terminal calls the second SDK and determines that the target host program does not have the corresponding first identifier, receive the second payment message sent by the user terminal through the network-wide payment platform by calling the second SDK.
  • the second payment message includes the host program identifier of the target host program and the first identifier corresponding to the target host program assigned by the entire network payment platform.
  • the host program platform when logging in to the target host program, receives the first identification request message sent by the user terminal to call the target host program, and the first identification request message includes user identity information; in response to the first identification request message, Send a second identification request message to the entire network payment platform.
  • the second identification request message is used to request the first identification.
  • the second identification request message includes user identity information and host program identification; receive the second identification feedback message sent by the entire network payment platform.
  • the second identification feedback message includes the first identification, which is obtained by the network-wide payment platform based on the user identity information, the host program identification and the pre-stored user identity information; according to the second identification feedback message, the target host of the user terminal The program sends a first identification feedback message, and the first identification feedback message includes the first identification.
  • step S5014 the target card is determined according to the second payment message.
  • Figure 12 is a flow chart of yet another embodiment of the payment method provided in the fourth aspect of this application. The difference between Figure 12 and Figure 10 is that the payment method shown in Figure 12 may also include step S503.
  • step S503 when the user applies for a resource card, user identity information is sent to the entire network payment platform, so that the entire network payment platform stores the user identity information as activated user identity information.
  • the following uses the first identification application process in the payment system, the e-commerce application triggering payment process, the payment code scanning payment process and the scanning collection code payment process as examples to illustrate some of the payment methods in the embodiment of the present application. process.
  • FIG 13 is a flow chart of an example of the first identification application process in the embodiment of the present application.
  • the application process for the first identification involves the host program in the terminal device, the second SDK, the host program platform and the entire network payment platform.
  • the application process for the first identification may include steps S601 to S611.
  • step S601 the host program sends a first identification request message to the host program platform.
  • step S602 the host program platform sends a second identification request message to the entire network payment platform.
  • step S603 the network-wide payment platform searches whether the user account in the host program has the first identifier based on the user identity information and the host program identifier in the second identification request message, that is, whether it has a full identity associated with the user account in the host program.
  • User account of the online payment platform If the user account in the host program does not have the first identifier, jump to step S604; if the user account in the host program has the first identifier, jump to step S609.
  • step S604 the entire network payment platform sends an unassociated account message to the host program platform to notify the host program platform that the entire network payment platform does not have a user account of the entire network payment platform that is associated with the user account in the host program.
  • step S605 the host program platform sends an account binding authorization request to the host program, requesting the user to authorize the binding of the user account in the host program with the user account of the entire network payment platform.
  • step S606 in response to the user's authorization input, the host program sends the first identification request message to the host program platform again.
  • the user's authorization input enters the user's identity information.
  • the user identity information in the first identification request message here is the user identity information that is authorized to be input.
  • step S607 the host program platform sends a second identification request message to the entire network payment platform.
  • the second identification request message includes user identity information, host program identification and user account of the user in the target host program.
  • step S608 the entire network payment platform performs account binding based on the second identification request message and the activated user identity information, that is, binds the user account in the host program with the user account of the entire network payment platform, and generates the first logo.
  • step S609 the entire network payment platform sends a second identification feedback message to the host program platform.
  • the second identification feedback message includes the first identification.
  • step S610 the host program platform sends a first identification feedback message to the host program.
  • the first identification feedback message includes the first identification.
  • step S611 the host program sends the first identifier and the host program identifier to the second SDK.
  • FIG 14 is a flow chart of an example of a payment process triggered by an e-commerce application in the embodiment of the present application.
  • the e-commerce application triggering the payment process may involve the e-commerce application in the user terminal, the first SDK, the host program, the second SDK, the host program platform and the entire network payment platform.
  • the host program refers to the target host program, and correspondingly, the host program platform refers to the host program platform of the target host program.
  • the whole-network payment platform can include channel sub-platforms and payment sub-platforms.
  • the channel sub-platform is mainly used to manage the relevant information of each host program and host program platform supported by the whole-network payment platform, and the payment sub-platform is used to manage the relevant information of each SDK.
  • the payment process triggered by the e-commerce application may include steps S701 to S719.
  • step S701 in response to the user's second input to the e-commerce application in the user terminal, the user terminal sends an order request to the omni-channel sub-platform through the e-commerce application.
  • step S702 the channel sub-platform generates order information in response to the order request, and feeds back the order information to the e-commerce application in the user terminal.
  • step S703 the e-commerce application is called in the user terminal to display an order page, where the order page includes order information.
  • step S704 the e-commerce application is called in the user terminal to trigger payment, and a first payment request message is sent to the channel sub-platform.
  • step S705 the channel sub-platform generates a first host program list in response to the first payment request information.
  • step S706 the channel sub-platform feeds back the first payment feedback message to the e-commerce application.
  • the first payment feedback message includes the first host program list.
  • step S707 the e-commerce application calls the first SDK to determine the target host program according to the first host program list, and calls up the target host program.
  • step S708 the target host program calls the second SDK of the target host program.
  • step S709 the user terminal calls the second SDK to check the user login status.
  • step S710 the user terminal calls the second SDK to send the version determination message and the SDK login determination message to the payment sub-platform.
  • step S711 the payment sub-platform determines whether the version of the second SDK is an available version and whether the second SDK is logged in based on the version determination message and the SDK login determination message, and feeds back the version feedback message and the SDK login feedback message to the second SDK.
  • step S712 the user terminal calls the second SDK to send a security determination message to the channel sub-platform.
  • step S713 the channel sub-platform determines whether the user account in the target host program and the resource transfer account for this payment are safe based on the security determination message, and feeds back the security feedback message to the second SDK.
  • step S714 the user terminal calls the second SDK to display payment details and request verification from the user.
  • step S715 after the user verification is successful, the second SDK sends a payment request to the channel sub-platform.
  • step S716 the channel sub-platform sends a payment request to the host program platform.
  • step S717 the host program platform deducts resources from the user's target card according to the payment request.
  • step S718 the host program platform feeds back the payment result to the channel sub-platform.
  • step S719 the channel sub-platform sends the payment result to the second SDK.
  • the payment code is scanned and paid, which can be divided into the payment code scanned payment in the application front mode and the payment code scanned payment in the resource card front mode.
  • the following are examples of payment by scanning payment codes in these two modes.
  • FIG 15 is a flowchart of an example of the payment code scanning payment process in the application pre-loading mode provided by the embodiment of the present application.
  • the payment code scanned payment process involves the second SDK of the host program in the user terminal, the entire network payment platform, the host program platform and the resource collector system.
  • the entire network payment platform may include a code management sub-platform, which is responsible for the management of payment codes and the management of additional information of the entire network payment platform.
  • the resource recipient system is the system to which the resources in the payment are transferred to the account, and may include payment acceptance terminal equipment or other equipment.
  • the payment process of scanning the payment code in the application preset mode may include steps S801a to S811a.
  • step S801a the user terminal calls the second SDK of the host program to send a payment code request to the code management sub-platform.
  • step S802a the code management sub-platform responds to the payment code request, generates a payment identifier, that is, a payment Token, converts the payment Token into a payment code, and issues the payment code to the second SDK.
  • a payment identifier that is, a payment Token
  • step S803a the user terminal calls the second SDK to display the payment code.
  • step S804a the resource recipient system scans the payment code and sends a payment request to the code management sub-platform.
  • step S805a the code management sub-platform sends an additional processing request to the second SDK.
  • Additional processing requests may include additional payment-related information. Additional information may include promotional information, event information, etc.
  • step S806a the user terminal calls the second SDK to send an additional processing result notification to the code management sub-platform.
  • the additional processing result notification includes information characterizing the situation in which the user selected additional information.
  • step S807a the code management sub-platform sends a payment request to the host program platform.
  • step S808a the host program platform deducts resources from the user's target card according to the payment request.
  • step S809a the host program platform feeds back the payment result to the code management sub-platform.
  • step S810a the code management sub-platform sends the payment result to the resource recipient system.
  • step S811a the code management sub-platform sends the payment result to the second SDK.
  • FIG 16 is a flow chart of an example of the payment code scanned payment process in the resource card front-end mode provided by the embodiment of the present application.
  • the payment code scanned payment process involves the second SDK of the host program in the user terminal, the entire network payment platform, the host program platform and the resource collector system.
  • the entire network payment platform may include a code management sub-platform, which is responsible for the management of payment codes and the management of additional information of the entire network payment platform.
  • the host program platform includes a host program sub-platform and a resource card front-end sub-platform.
  • the host program sub-platform is responsible for interacting with the host program, and the resource card front-end sub-platform is responsible for deducting and transferring resources in the card.
  • the resource recipient system is the system to which the resources in the payment are transferred to the account, and may include payment acceptance terminal equipment or other equipment.
  • the payment process when the payment code is scanned in the resource card front-end mode may include steps S801b to S812b.
  • step S801b the user terminal calls the second SDK of the host program to send a payment code request to the code management sub-platform.
  • step S802b the code management sub-platform responds to the payment code request, generates a payment identifier, that is, a payment Token, converts the payment Token into a payment code, and issues the payment code to the second SDK.
  • a payment identifier that is, a payment Token
  • step S803b the user terminal calls the second SDK to display the payment code.
  • step S804b the resource recipient system scans the payment code and sends a payment request to the code management sub-platform.
  • step S805b the code management sub-platform sends an additional processing request to the second SDK.
  • Additional processing requests may include additional payment-related information. Additional information can include promotion information, event information, etc.
  • step S806b the user terminal calls the second SDK to send an additional processing result notification to the code management sub-platform.
  • the additional processing result notification includes information characterizing the situation in which the user selected additional information.
  • step S807b the code management sub-platform sends a payment request to the resource card front-end sub-platform.
  • step S808b the resource card front-end sub-platform deducts resources from the user's target card according to the payment request.
  • step S809b the resource card front-end sub-platform feeds back the payment results to the code management sub-platform.
  • step S810b the code management sub-platform sends the payment result to the resource recipient system.
  • step S811b the code management sub-platform sends the payment result to the second SDK.
  • step S812b the code management sub-platform sends the payment result to the host program sub-platform.
  • scan and receive code payment can be divided into application front-end mode scan and receive code payment and resource card front-end mode scan and receive code payment.
  • application front-end mode scan and receive code payment and resource card front-end mode scan and receive code payment.
  • FIG 17 is a flow chart of an example of the payment process of scanning and receiving codes in the application pre-loading mode provided by the embodiment of the present application.
  • the scanning and receiving code payment process involves the second SDK of the host program in the user terminal, the entire network payment platform, the host program platform and the resource collector system.
  • the entire network payment platform may include a code management sub-platform, which is responsible for the management of collection codes.
  • the resource recipient system is the system of the owner of the account to which the resources in payment are transferred.
  • the scan-to-receive-code payment process in the application front-end mode may include steps S801c to S806c.
  • step S801c the user terminal calls the second SDK of the host program to scan the collection code and sends a payment request to the code management sub-platform.
  • the code management sub-platform responds to the payment request and sends a resource deduction request to the host program platform.
  • the resource deduction request may include resource deductor information, resource deduction amount, resource transfer account owner code, resource transfer account owner category, resource transfer account owner name, additional information, etc. Additional information can include promotion information, event information, etc.
  • step S803c the host program platform deducts resources from the user's target card in response to the resource deduction request.
  • step S804c the host program platform sends the resource deduction result to the code management sub-platform.
  • the resource deduction result indicates successful deduction or failed deduction.
  • step S805c the code management sub-platform sends the resource deduction result to the second SDK.
  • step S806c the code management sub-platform sends the payment result to the resource recipient system.
  • the payment result may include resource deductor information, resource deduction amount, resource transfer account owner code, resource transfer account owner category, resource transfer account owner name, additional information, etc.
  • FIG 18 is a flow chart of an example of the payment process of scanning and receiving codes in the resource card front-end mode provided by the embodiment of the present application.
  • the scanning and receiving code payment process involves the second SDK of the host program in the user terminal, the entire network payment platform, the host program platform and the resource collector system.
  • the entire network payment platform may include a code management sub-platform, which is responsible for the management of payment codes.
  • the host program platform includes a host program sub-platform and a resource card front-end sub-platform.
  • the host program sub-platform is responsible for interacting with the host program, and the resource card front-end sub-platform is responsible for deducting and transferring resources in the card.
  • the resource recipient system is the system of the owner of the account to which the resources in payment are transferred.
  • the scan and receive code payment process in the application pre-loading mode may include steps S801d to S807d.
  • step S801d the user terminal calls the second SDK of the host program to scan the collection code and sends a payment request to the code management sub-platform.
  • step S802d the code management sub-platform responds to the payment request and sends a resource deduction request to the resource card front-end sub-platform.
  • step S803d the resource card front-end sub-platform responds to the resource deduction request and deducts resources from the user's target card.
  • step S804d the resource card front-end sub-platform sends the resource deduction result to the code management sub-platform.
  • step S805d the code management sub-platform sends the resource deduction result to the second SDK.
  • step S806d the code management sub-platform sends the resource deduction result to the resource recipient system.
  • step S807d the code management sub-platform sends the resource deduction result to the host program sub-platform.
  • a fifth aspect of the present application provides a user terminal, which has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • Figure 19 is a schematic structural diagram of an embodiment of a user terminal provided in the fifth aspect of this application. As shown in Figure 19, the user terminal 900 includes a calling module 901 and an interaction module 902.
  • the calling module 901 can be used to call the first SDK and use the interaction module 902 to obtain the first host program list from the entire network payment platform when the e-commerce application triggers payment, and is also used to call the first SDK in the first host.
  • the target host program is determined in the program list, the target host program is called.
  • the first host program list includes host program identifiers of at least some host programs supported by the entire network payment platform.
  • the calling module 901 can also be used to call the second SDK through the target host program to interact with the entire network payment platform using the interaction module 902, so that the entire network payment platform interacts with the host program platform to complete the payment of the target card.
  • the target card is a resource card bound to the target host program.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the first SDK can interact with the entire network payment platform to obtain a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that when the first SDK determines the target host program, the user The terminal can call up the target host program.
  • the target host program can call the second SDK integrated by itself.
  • the second SDK can interact with the entire network payment platform.
  • the entire network payment platform can interact with the host program platform of the target host program to execute the target card bound to the target host program. Resources are deducted and payment is completed.
  • E-commerce applications and different host programs in user terminals can interact with the entire network payment platform through their respective integrated SDKs, so that the entire network payment platform can interact with the host program background corresponding to different applications, making the payment process different.
  • the unified payment technical specifications among card issuing banks and other institutions realize unified management of payments and reduce the difficulty of payment management.
  • the host program platforms corresponding to different host programs share the same network-wide payment platform. Different host programs share the same network-wide payment platform through their respective integrated SDKs. Payment management is no longer restricted by the host program of the card issuer or other institution to which the payment account belongs. , the user payment experience is unified, and users do not need to use different operating methods for different host program payments, which improves the user's payment experience.
  • the interaction module 902 may include a sending unit and a receiving unit.
  • the calling module 901 can be used to use the sending unit to send the first payment request message to the entire network payment platform through the e-commerce application.
  • the first payment request message includes a user identification and is used to instruct the entire network payment platform to generate a first host program list based on historical payment data corresponding to the user identification and/or a pre-stored payment priority policy.
  • the first host program list includes host program identifiers of N host programs arranged from high to low priority, where N is a positive integer.
  • the receiving unit may be used to receive the first payment feedback message sent by the entire network payment platform.
  • the first payment feedback message includes the first host program list.
  • the above-mentioned calling module 901 can also be used to: call the first SDK to obtain a second host program list locally, where the second host program list includes the host program identification of the host program owned by the user terminal; call the first SDK to obtain the second host program list.
  • the intersection of a host program list and a second host program list displays the intersection; in response to the user's first input, the host program corresponding to the host program identifier indicated by the first input in the intersection is determined as the target host program.
  • the above-mentioned calling module 901 can also be used to: call the first SDK to obtain a second host program list locally, where the second host program list includes the host program identification of the host program owned by the user terminal; call the first SDK to obtain the second host program list.
  • the intersection of the first host program list and the second host program list determines the host program with the highest priority corresponding to the host program identifier in the intersection as the target host program.
  • the above-mentioned calling module 901 can be used to call the second SDK to query whether the target host program has a corresponding first identifier.
  • the first identifier is used to indicate that the user account in the host program has the function of making payments using the entire network payment platform. .
  • the calling module 901 can be used to call the second SDK to use the sending unit to send the first payment message to the entire network payment platform when the target host program has a corresponding first identifier, so that the entire network payment platform sends the first payment message to the host program platform.
  • the host program platform performs the resource deduction of the target card and completes the payment of the target card.
  • the first payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the calling module 901 can be used to call the target host program to request the entire network payment platform for the third identity corresponding to the target host program through the host program platform using the interaction module 902 when the target host program does not have a corresponding first identifier.
  • a logo e.g., A logo.
  • the calling module 901 can also be used to call the target host program utilization receiving unit to receive the first identifier corresponding to the target host program distributed by the entire network payment platform through the host program platform.
  • the calling module 901 can also be used to call the second SDK to use the sending unit to send the second payment message to the entire network payment platform, so that the entire network payment platform sends the second payment message to the host program platform, and the host program platform performs the resource deduction of the target card. , complete the payment of the target card.
  • the second payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the calling module 901 may be configured to call the target host program to use the sending unit to send the first identification request message to the host program platform when logging in to the target host program.
  • the first identification request message includes user identity information and is used to instruct the host program platform to send the second identification request message to the entire network payment platform.
  • the second identification request message is used to request the first identification.
  • the second identification request message includes user identity information and host program identification.
  • the calling module 901 can be used to call the target host program to use the receiving unit to receive the first identification feedback message sent by the host program platform.
  • the first identification feedback message includes the first identification.
  • the first identification feedback information is generated based on the second identification feedback message sent by the entire network payment platform to the host program platform.
  • the second identification feedback message includes the first identification.
  • the first identification is obtained by the entire network payment platform based on user identity information, host program identification and pre-stored user identity information.
  • the subscribed user identity information includes the user identity information sent by the host program platform to the entire network payment platform when the user applies for a resource card.
  • the calling module 901 can also be used to call the second SDK of the target host program to use the sending unit to send a version determination message to the entire network payment platform.
  • the version determination message instructs the entire network payment platform to determine whether the version of the second SDK is an available version.
  • the calling module 901 may also be configured to receive the version feedback message sent by the entire network payment platform through the second SDK utilization receiving unit of the target host program.
  • the version feedback message indicates whether the version of the second SDK is an available version.
  • the calling module 901 can also be used to call the second SDK utilization sending unit of the target host program to send the SDK login determination message to the entire network payment platform.
  • the SDK login determination message instructs the entire network payment platform to determine whether the second SDK is logged in.
  • the calling module 901 may also be configured to receive the SDK login feedback message sent by the entire network payment platform through the second SDK utilization receiving unit of the target host program.
  • the SDK login feedback message indicates whether the second SDK version is logged in.
  • the calling module 901 can also be used to call the second SDK of the target host program to use the sending unit to send the security determination message to the entire network payment platform.
  • the security determination message instructs the entire network payment platform to determine whether the user account in the target host program and the account to which the resources for this payment are transferred are safe.
  • the calling module 901 can also be used to receive the security feedback message sent by the entire network payment platform through the second SDK utilization receiving unit of the target host program.
  • the security feedback message indicates whether the user account and resource transfer account in the target host program are safe.
  • user terminal 900 also includes a processing module.
  • the calling module 901 can also be used to respond to the user's second input and use the interactive module 902 to obtain order information from the entire network payment platform through the e-commerce application.
  • the processing module may be used to trigger payment in response to a third user input to the order page.
  • the order page includes order information.
  • the calling module 901 can also be used to call the second SDK to obtain the payment code from the entire network payment platform through the interactive module.
  • the payment code is used to be scanned by the payment acceptance terminal to initiate a payment request to the entire network payment platform;
  • the calling module 901 can also be used to call the second SDK to scan and receive the code.
  • the interaction module 902 can also be used to initiate a payment request to the entire network payment platform.
  • a sixth aspect of the present application provides a payment management device, which is the device in the network-wide payment platform in the above embodiment.
  • Figure 20 is a schematic structural diagram of an embodiment of the payment management device provided in the sixth aspect of this application.
  • the payment management device 1000 includes an interaction module 1001 , and the interaction module 1001 may include a sending unit 10011 .
  • the interaction module 1001 may also include a receiving unit 10012.
  • the sending unit 10011 may be configured to provide a first host program list to the first software development tool kit SDK integrated with the e-commerce application in the user terminal when the e-commerce application in the user terminal triggers payment.
  • the user terminal has an e-commerce application, a first SDK, a host program, and a second SDK integrated with the host program.
  • the first host program list includes host program identifiers of at least some host programs supported by the entire network payment platform, and is used to enable the user terminal to call the first SDK to determine and call up the target host program.
  • the interaction module 1001 can be used to interact with the second SDK and host program platform called by the user terminal through the target host program to complete the payment of the target card.
  • the target card is a resource card bound to the target host program.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the entire network payment platform can interact with the first SDK and provide the first SDK with a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that the first SDK determines the target host program.
  • the user terminal can call up the target host program.
  • the network-wide payment platform can interact with the second SDK integrated with the target host program itself, and can also interact with the host program platform of the target host program, allowing the host program platform to perform resource deductions on the target card bound to the target host program to complete the payment.
  • the entire network payment platform can interact with e-commerce applications in user terminals and SDKs integrated with different host programs. It can also interact with the host program background corresponding to different applications to enable payments between different card issuers and other institutions during the payment process.
  • the unified technical specifications realize unified management of payments and reduce the difficulty of payment management.
  • the host program platforms corresponding to different host programs share the same network-wide payment platform. Different host programs share the same network-wide payment platform through their respective integrated SDKs. Payment management is no longer restricted by the host program of the card issuer or other institution to which the payment account belongs. , the user payment experience is unified, and users do not need to use different operating methods for different host program payments, which improves the user's payment experience.
  • the payment management device 1000 may further include a processing module.
  • Figure 21 is a schematic structural diagram of another embodiment of the payment management device provided in the sixth aspect of this application. The difference between Figure 21 and Figure 20 is that the payment management device 1000 shown in Figure 21 may also include a processing module 1002.
  • the receiving unit 10012 may be used to receive a first payment request message sent by the user terminal through an e-commerce application, where the first payment request message includes a user identification,
  • the processing module 1002 can be used to: obtain the priority order of host programs supported by the entire network payment platform based on the historical payment data corresponding to the user identification and/or the pre-stored payment priority policy; based on the top N from high to low priority
  • the host program identifier of the host program generates the first host program list, N is a positive integer.
  • the sending unit 10011 may be configured to send a first payment feedback message to the e-commerce application of the user terminal, where the first payment feedback message includes a first host program list.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program corresponding to the host program identifier specified by the user in the intersection of the first host program list and the second host program list.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program with the highest priority corresponding to the host program identifier in the intersection of the first host program list and the second host program list.
  • the receiving unit 10012 may be configured to receive the first payment message sent by the user terminal by calling the second SDK when the user terminal calls the second SDK to determine that the target host program has a corresponding first identifier.
  • the first identifier is used to indicate that the user account in the host program has the function of making payments using the entire network payment platform.
  • the sending unit 10011 may be used to send the first payment message to the host program platform.
  • the first payment message instructs the host program platform to perform resource deduction of the target card and complete the payment of the target card.
  • the first payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the sending unit 10011 may be configured to provide the first identifier to the target host program through the host program platform when the user terminal calls the second SDK to determine that the target host program does not have a corresponding first identifier.
  • the receiving unit 10012 may be configured to receive the second payment message sent by the user terminal by calling the second SDK.
  • the sending unit 10011 may be used to send the second payment message to the host program platform.
  • the second payment message instructs the host program platform to perform resource deduction of the target card and complete the payment of the target card.
  • the second payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the receiving unit 10012 may be configured to receive the second identification request message sent by the host program platform when logging in to the target host program.
  • the second identification request message includes user identity information and host program identification.
  • the second identification request message is generated according to the first identification request message sent by the terminal device by calling the target host program.
  • the first identification request message includes user identity information.
  • the processing module 1002 may be configured to assign a first identity to the target host program based on the user identity information, the host program identity and the pre-stored subscribed user identity information.
  • the sending unit 10011 may be configured to send a second identification feedback message to the host program platform, so that the host program platform sends a first identification feedback message to the target host program according to the second identification feedback message.
  • the first identification feedback message and the second identification feedback message include the first identification.
  • the user identity information includes a first user unique identifier and a first phone number
  • the subscribed user identity information includes a second user unique identifier and a second phone number
  • the processing module 1002 may also be configured to bind the first user account and the second user account and generate the first identification when the subscribed user identity information includes the unique identification of the target second user.
  • the target second user's unique identifier is a second user's unique identifier that is consistent with the first user's unique identifier.
  • the first user account is the user account corresponding to the first user's unique identifier in the target host program.
  • the second user account is the user account corresponding to the target second user's unique identifier and the target second phone number in the entire network payment platform.
  • the target second phone number is a second phone number that is consistent with the first phone number.
  • the processing module 1002 can also be used to create a new third user account, bind the first user account and the third user account, and generate the first identification when the subscribed user identity information does not include the unique identification of the target second user.
  • the third user account is the user account corresponding to the first user's unique identifier in the entire network payment platform.
  • the receiving unit 10012 may also be configured to receive a version determination message sent by the user terminal calling the second SDK of the target host program.
  • the processing module 1002 may also be configured to determine whether the version of the second SDK is an available version according to the version determination message.
  • the sending unit 10011 may also be configured to send a version feedback message to the second SDK of the target host program, where the version feedback message indicates whether the version of the second SDK is an available version.
  • the receiving unit 10012 may also be configured to receive an SDK login determination message sent by the user terminal calling the second SDK of the target host program.
  • the processing module 1002 may also be used to determine whether the second SDK is logged in based on the SDK login determination message.
  • the sending unit 10011 may also be used to send an SDK login feedback message to the second SDK of the target host program, where the SDK login feedback message indicates whether the second SDK is logged in.
  • the receiving unit 10012 may also be configured to receive a security determination message sent by the user terminal calling the second SDK of the target host program.
  • the processing module 1002 can also be used to determine whether the user account in the target host program and the account to which the resources for this payment are transferred are safe based on the security determination message.
  • the sending module 10011 can also be used to send a security feedback message to the second SDK of the target host program.
  • the security feedback message indicates whether the user account and resource transfer account in the target host program are safe.
  • the receiving unit 10012 may also be configured to receive user identity information sent by the host program platform when the user applies for a resource card.
  • the processing module 1002 can also be used to store user identity information as subscribed user identity information.
  • the sending unit 10011 may also be configured to provide order information for the e-commerce application in response to an order request from the e-commerce application.
  • the sending unit 10011 may also be configured to send a payment code to the second SDK in response to a payment code request from the user terminal calling the second SDK.
  • the receiving unit 10012 can also be used to receive a payment request initiated by a payment acceptance terminal scanning a payment code, and interact with the host program platform to complete the payment indicated by the payment request.
  • the receiving unit 10012 may also be configured to receive a payment request initiated by the user terminal by calling the second SDK to scan the collection code.
  • the interaction module 1001 can be used to interact with the host program platform to complete the payment indicated by the payment request.
  • a seventh aspect of the present application provides a background service device, which is a device in the host program platform in the above embodiment.
  • Figure 22 is a schematic structural diagram of an embodiment of the background service device provided in the seventh aspect of this application.
  • the background service device 1100 includes an interaction module 1101 and an execution module 1102.
  • the interaction module 1101 can be used to interact with the entire network payment platform to determine the target card for payment when the e-commerce application of the user terminal triggers payment.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the target card is a resource card bound to the target host program.
  • the target card is determined based on the interaction between the second SDK of the target host program called by the user terminal and the entire network payment platform.
  • the target host program is the user terminal that calls the host program determined by the first SDK in the first host program list.
  • the first host program list includes host program identifiers of at least some host programs supported by the entire network payment platform.
  • the first host program list includes host program identifiers of N host programs arranged from high to low priority, N is an integer, and the priority is based on historical payment data corresponding to the user identifier provided by the user terminal through the e-commerce application. and/or pre-stored payment priority policy determination.
  • the execution module 1102 may be used to execute the resource deduction of the target card to complete the payment of the target card.
  • the user terminal has an e-commerce application, a first SDK integrated with the e-commerce application, a host program, and a second SDK integrated with the host program.
  • the entire network payment platform can interact with the first SDK and provide the first SDK with a list including host program identifiers of at least some host programs supported by the entire network payment platform, so that the first SDK determines the target host program.
  • the user terminal can call up the target host program.
  • the network-wide payment platform can interact with the second SDK integrated with the target host program itself, and can also interact with the host program platform of the target host program, allowing the host program platform to perform resource deductions on the target card bound to the target host program to complete the payment.
  • the entire network payment platform can interact with e-commerce applications in user terminals and SDKs integrated with different host programs. It can also interact with the host program background corresponding to different applications to enable payments between different card issuers and other institutions during the payment process.
  • the unified technical specifications realize unified management of payments and reduce the difficulty of payment management.
  • the host program platforms corresponding to different host programs share the same network-wide payment platform. Different host programs share the same network-wide payment platform through their respective integrated SDKs. Payment management is no longer restricted by the host program of the card issuer or other institution to which the payment account belongs. , the user payment experience is unified, and users do not need to use different operating methods for different host program payments, which improves the user's payment experience.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program corresponding to the host program identifier specified by the user in the intersection of the first host program list and the second host program list.
  • the second host program list includes host program identifications of host programs owned by the user terminal.
  • the target host program is the host program with the highest priority corresponding to the host program identifier in the intersection of the first host program list and the second host program list.
  • the interaction module 1101 can be used to receive the first payment sent by the user terminal through the network-wide payment platform by calling the second SDK when the user terminal calls the second SDK to determine that the target host program has a corresponding first identifier. information.
  • the first payment message includes a host program identifier of the target host program and a first identifier corresponding to the target host program.
  • the execution module 1102 may be used to determine the target card according to the first payment message.
  • the interaction module 1101 may be used to receive the second message sent by the network-wide payment platform when the user terminal calls the second SDK and determines that the target host program does not have a corresponding first identifier. Payment message.
  • the second payment message includes the host program identifier of the target host program and the first identifier corresponding to the target host program assigned by the entire network payment platform;
  • the execution module 1102 may be used to determine the target card according to the second payment message.
  • the interaction module 1101 may also be configured to receive a first identification request message sent by the user terminal to call the target host program when logging in to the target host program.
  • the first identification request message includes user identity information.
  • the interaction module 1101 may also be configured to respond to the first identification request message and send a second identification request message to the entire network payment platform.
  • the second identification request message is used to request the first identification.
  • the second identification request message includes user identity information and host program identification.
  • the interaction module 1101 can also be used to receive the second identification feedback message sent by the entire network payment platform.
  • the second identification feedback message includes the first identification.
  • the first identification is obtained by the entire network payment platform based on user identity information, host program identification and pre-stored user identity information.
  • the interaction module 1101 may also be configured to send a first identification feedback message to the target host program of the user terminal according to the second identification feedback message.
  • the first identification feedback message includes the first identification.
  • the interaction module 1101 can also be used to send user identity information to the entire network payment platform when the user applies for a resource card, so that the entire network payment platform stores the user identity information as activated user identity information.
  • FIG. 23 is a schematic structural diagram of an embodiment of a user terminal provided in the eighth aspect of this application.
  • the user terminal 1200 includes a memory 1201, a processor 1202, and a computer program stored on the memory 1201 and executable on the processor 1202.
  • the above-mentioned processor 1202 may include a central processing unit (CPU), or an Application Specific Integrated Circuit (ASIC), or may be configured to implement one or more integrated circuits of embodiments of the present application.
  • CPU central processing unit
  • ASIC Application Specific Integrated Circuit
  • Memory 1201 may include read-only memory (ROM), random access memory (Random Access Memory, RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical/tangible devices Memory storage device.
  • ROM read-only memory
  • RAM random access memory
  • magnetic disk storage media devices magnetic disk storage media devices
  • optical storage media devices flash memory devices
  • electrical, optical or other physical/tangible devices Memory storage device electrical, optical or other physical/tangible devices Memory storage device.
  • memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or multiple processors), it is operable to perform the operations described with reference to the payment method in the embodiment according to the second aspect of the present application.
  • the processor 1202 reads the executable program code stored in the memory 1201 to run the computer program corresponding to the executable program code, so as to implement the payment method in the embodiment of the second aspect.
  • user terminal 1200 may also include communication interface 1203 and bus 1204. Among them, as shown in Figure 23, the memory 1201, the processor 1202, and the communication interface 1203 are connected through the bus 1204 and complete communication with each other.
  • the communication interface 1203 is mainly used to implement communication between modules, devices, units and/or equipment in the embodiments of this application. Input devices and/or output devices may also be accessed through the communication interface 1203.
  • Bus 1204 includes hardware, software, or both, coupling the components of user terminal 1200 to each other.
  • the bus 1204 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), Hyper Transport (HT) interconnect, Industry Standard Architecture (ISA) bus, infinite bandwidth interconnect, low pin count (LPC) bus, memory bus, Micro Channel architecture Architecture, MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-E) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association part ( Video Electronics Standards Association Local Bus, VLB) bus or other suitable bus or a combination of two or more of these.
  • bus 1204 may include one or more buses.
  • a ninth aspect of this application provides a payment management device.
  • the payment management device is the device in the entire network payment platform in the above embodiment.
  • the payment management device may include a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the payment management device may also include a communication interface and bus. The memory, processor, and communication interface can be connected through the bus and communicate with each other.
  • memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processor), it is operable to perform the operations described with reference to the payment method in the embodiment according to the third aspect of the present application.
  • the tenth aspect of this application provides a background service device.
  • the background server device is a device in the host program platform in the above embodiment.
  • the background service device may include a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the payment management device may also include a communication interface and bus. The memory, processor, and communication interface can be connected through the bus and communicate with each other.
  • memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processor), it is operable to perform the operations described with reference to the payment method in the embodiment according to the fourth aspect of the present application.
  • An eleventh aspect of this application provides a payment system, which may include the user terminal, payment management device and backend service device in the above embodiment.
  • a payment system which may include the user terminal, payment management device and backend service device in the above embodiment.
  • the specific content of the user terminal please refer to the relevant descriptions in the above embodiments.
  • the specific content of the payment management equipment please refer to the relevant descriptions of the entire network payment platform, payment management device and payment management equipment in the above embodiments.
  • the specific content of the backend service equipment Please refer to the relevant contents of the host program platform, background service device and background service equipment in the above embodiments, which will not be described again here.
  • a twelfth aspect of the present application provides a computer-readable storage medium.
  • Computer program instructions are stored on the computer-readable storage medium. When executed by a processor, the computer program instructions can implement the payment method in the embodiment of the present application, and can To achieve the same technical effect, to avoid repetition, we will not repeat them here.
  • the above-mentioned computer-readable storage media may include non-transitory computer-readable storage media, such as read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), magnetic disks or optical disks etc. are not limited here.
  • the present application can also provide a computer program product.
  • the electronic device causes the electronic device to execute the payment method in the embodiment of the present application.
  • the electronic device may include the user terminal, payment management device, and background service device in the above embodiments.
  • Such a processor may be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It will also be understood that each block in the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can also be implemented by special purpose hardware that performs the specified functions or actions, or can be implemented by special purpose hardware and A combination of computer instructions.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请公开了一种支付方法、用户终端、装置、设备、系统及介质,属于数据处理领域。该方法包括:在电子商务应用程序触发支付的情况下,调用第一SDK从全网支付平台获取第一宿主程序列表,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识;在调用第一SDK在第一宿主程序列表中确定目标宿主程序的情况下,调起目标宿主程序;通过目标宿主程序调用第二SDK与全网支付平台交互,以使全网支付平台与宿主程序平台交互,完成目标卡的支付,目标卡为与目标宿主程序绑定的一张资源卡。

Description

支付方法、用户终端、装置、设备、系统及介质
相关申请的交叉引用
本申请要求享有于2022年03月24日提交的名称为“支付方法、用户终端、装置、设备、系统及介质”的中国专利申请202210294467.6的优先权,该申请的全部内容通过引用并入本文中。
技术领域
本申请属于数据处理,尤其涉及一种支付方法、用户终端、装置、设备、系统及介质。
背景技术
随着支付技术的发展,越来越多的用户选择利用用户终端进行电子支付。为了满足用户对电子支付的需求,各发卡行或其他机构开发并向用户提供应用程序,以使得用户可通过应用程序来完成电子支付。
但不同发卡行及其他机构之间的支付标识、技术规范等均有不同,各发卡行或其他机构各自开发的应用程序也不同,无法对支付进行统一管理,对支付的管理难度较大。
发明内容
本申请实施例提供一种支付方法、用户终端、装置、设备、系统及介质,能够对支付统一管理,降低支付管理的难度。
第一方面,本申请实施例提供一种支付方法,应用于支付系统,支付系统包括用户终端、全网支付平台和宿主程序平台,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一软件开发工具包(Software Development Kit,SDK)、宿主程序以及与宿主程序集成的第二SDK,电子商务应用程序所属第一主体,宿主程序所属第二主体,第一SDK和第 二SDK所属第三主体,
该方法包括:在电子商务应用程序触发支付的情况下,用户终端调用第一SDK与全网支付平台交互,获取第一宿主程序列表,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识;在调用第一SDK在第一宿主程序列表中确定目标宿主程序的情况下,用户终端调起目标宿主程序;用户终端通过目标宿主程序调用第二SDK与全网支付平台交互,全网支付平台与宿主程序平台交互,宿主程序平台执行目标卡的资源扣除,以完成目标卡的支付,目标卡为与目标宿主程序绑定的一张资源卡。
第二方面,本申请实施例提供一种支付方法,应用于用户终端,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与宿主程序集成的第二SDK,
该方法包括:在电子商务应用程序触发支付的情况下,调用第一SDK从全网支付平台获取第一宿主程序列表,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识;在调用第一SDK在第一宿主程序列表中确定目标宿主程序的情况下,调起目标宿主程序;通过目标宿主程序调用第二SDK与全网支付平台交互,以使全网支付平台与宿主程序平台交互,完成目标卡的支付,目标卡为与目标宿主程序绑定的一张资源卡。
第三方面,本申请实施例提供一种支付方法,应用于全网支付平台,该方法包括:在用户终端的电子商务应用程序触发支付的情况下,向用户终端中与电子商务应用程序集成的第一软件开发工具包SDK提供第一宿主程序列表,用户终端具有电子商务应用程序、第一SDK、宿主程序以及与宿主程序集成的第二SDK,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识,用于使用户终端调用第一SDK确定并调起目标宿主程序;与用户终端通过目标宿主程序调用的第二SDK、宿主程序平台交互,完成目标卡的支付,目标卡为与目标宿主程序绑定的一张资源卡。
第四方面,本申请实施例提供一种支付方法,应用于宿主程序平台, 该方法包括:在用户终端的电子商务应用程序触发支付的情况下,与全网支付平台交互,确定用于支付的目标卡,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与宿主程序集成的第二SDK,目标卡为与目标宿主程序绑定的一张资源卡,目标卡根据用户终端调用的目标宿主程序的第二SDK与全网支付平台交互确定,目标宿主程序为用户终端调用第一SDK在第一宿主程序列表中确定的宿主程序,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识;执行目标卡的资源扣除,以完成目标卡的支付。
第五方面,本申请实施例提供一种用户终端,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与宿主程序集成的第二SDK,用户终端包括调用模块和交互模块;调用模块用于在电子商务应用程序触发支付的情况下,调用第一SDK利用交互模块从全网支付平台获取第一宿主程序列表,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识;以及,还用于在调用第一SDK在第一宿主程序列表中确定目标宿主程序的情况下,调起目标宿主程序;调用模块用于通过目标宿主程序调用第二SDK利用交互模块与全网支付平台交互,以使全网支付平台与宿主程序平台交互,完成目标卡的支付,目标卡为与目标宿主程序绑定的一张资源卡。
第六方面,本申请实施例提供一种支付管理装置,包括交互模块,交互模块包括发送单元;发送单元,用于在用户终端的电子商务应用程序触发支付的情况下,向用户终端中与电子商务应用程序集成的第一软件开发工具包SDK提供第一宿主程序列表,用户终端具有电子商务应用程序、第一SDK、宿主程序以及与宿主程序集成的第二SDK,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识,用于使用户终端调用第一SDK确定并调起目标宿主程序;交互模块,用于与用户终端通过目标宿主程序调用的第二SDK、宿主程序平台交互,完成目标卡的支付,目标卡为与目标宿主程序绑定的一张资源卡。
第七方面,本申请实施例提供一种后台服务装置,包括:交互模块, 用于在用户终端的电子商务应用程序触发支付的情况下,与全网支付平台交互,确定用于支付的目标卡,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与宿主程序集成的第二SDK,目标卡为与目标宿主程序绑定的一张资源卡,目标卡根据用户终端调用的目标宿主程序的第二SDK与全网支付平台交互确定,目标宿主程序为用户终端调用第一SDK在第一宿主程序列表中确定的宿主程序,第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识;执行模块,用于执行目标卡的资源扣除,以完成目标卡的支付。
第八方面,本申请实施例提供一种用户终端,包括:处理器以及存储有计算机程序指令的存储器;处理器执行计算机程序指令时实现第二方面的支付方法。
第九方面,本申请实施例提供一种支付管理设备,包括:处理器以及存储有计算机程序指令的存储器;处理器执行计算机程序指令时实现第三方面的支付方法。
第十方面,本申请实施例提供一种后台服务设备,包括:处理器以及存储有计算机程序指令的存储器;处理器执行计算机程序指令时实现第四方面的支付方法。
第十一方面,本申请实施例提供一种支付系统,包括第八方面的用户终端、第九方面的支付管理设备和第十方面的后台服务设备。
第十二方面,本申请实施例提供一种计算机可读存储介质,计算机可读存储介质上存储有计算机程序指令,计算机程序指令被处理器执行时实现如第一方面、第二方面、第三方面、第四方案中任意一方面的支付方法。
本申请实施例提供一种支付方法、用户终端、装置、设备、系统及介质,其中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,第一SDK可与全网支付平台交互,获取包括全网支付平台支持的至少部分宿主程序的宿主程序标识的列表,以使在第一SDK确定目标宿主程序 的情况下,用户终端可调起目标宿主程序。目标宿主程序可调用自身集成的第二SDK,第二SDK可与全网支付平台交互,全网支付平台可与目标宿主程序的宿主程序平台交互,以执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。用户终端中电子商务应用程序以及不同的宿主程序都可通过各自集成的SDK与全网支付平台交互,以使全网支付平台再与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一,实现了对支付的统一管理,降低了支付管理的难度。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单的介绍,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的用户、发卡行、卡组织和收单机构的四方模式的一示例的架构示意图;
图2为本申请第一方面提供的支付方法的一实施例的流程图;
图3为本申请第一方面提供的支付方法的另一实施例的流程图;
图4为本申请第一方面提供的支付方法的又一实施例的流程图;
图5为本申请第二方面提供的支付方法的一实施例的流程图;
图6为本申请第二方面提供的支付方法的另一实施例的流程图;
图7为本申请第三方面提供的支付方法的一实施例的流程图;
图8为本申请第三方面提供的支付方法的另一实施例的流程图;
图9为本申请第三方面提供的支付方法的又一实施例的流程图;
图10为本申请第四方面提供的支付方法的一实施例的流程图;
图11为本申请第四方面提供的支付方法的另一实施例的流程图;
图12为本申请第四方面提供的支付方法的又一实施例的流程图;
图13为本申请实施例中第一标识申请流程的一示例的流程图;
图14为本申请实施例中电子商务应用程序触发支付流程的一示例的流程图;
图15为本申请实施例提供的应用程序前置模式的支付码被扫支付流程的一示例的流程图;
图16为本申请实施例提供的资源卡前置模式的支付码被扫支付流程的一示例的流程图;
图17为本申请实施例提供的应用程序前置模式的扫描收取码支付流程的一示例的流程图;
图18为本申请实施例提供的资源卡前置模式的扫描收取码支付流程的一示例的流程图;
图19为本申请第五方面提供的用户终端的一实施例的结构示意图;
图20为本申请第六方面提供的支付管理装置的一实施例的结构示意图;
图21为本申请第六方面提供的支付管理装置的另一实施例的结构示意图;
图22为本申请第七方面提供的后台服务装置的一实施例的结构示意图;
图23为本申请第八方面提供的用户终端的一实施例的结构示意图。
具体实施方式
下面将详细描述本申请的各个方面的特征和示例性实施例,为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及具体实施例,对本申请进行进一步详细描述。应理解,此处所描述的具体实施例仅意在解释本申请,而不是限定本申请。对于本领域技术人员来说,本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。
随着支付技术的发展,越来越多的用户选择利用用户终端进行电子支付。为了满足用户对电子支付的需求,各发卡行或其他机构开发并向用户提供应用程序,以使得用户可通过应用程序来完成电子支付。但不同发卡行及其他机构之间的支付标识、技术规范等均有不同,各发卡行或其他机构各自开发的应用程序也不同,无法对支付进行统一管理,对支付的管理 难度较大。
本申请实施例提供一种支付方法、用户终端、装置、设备、系统及介质,能够提供一种基于用户、发卡行、卡组织和收单机构进行支付的四方模式,使得各类电子支付均可统一管理,降低支付的管理难度。
图1为本申请实施例提供的用户、发卡行、卡组织和收单机构的四方模式的一示例的架构示意图。如图1所示,用户11可进行账户的注册以及四方模式下支付功能的开通和授权,用户11还可通过用户终端12进行支付,图1中的用户终端12属于用户11一方。支付方式可包括通过电子商务应用程序发起的支付、扫码支付等,在此并不限定。用户终端12可包括手机、平板电脑、可穿戴设备等可进行支付的终端设备,在此并不限定用户终端12的类型。用户终端12中具有电子商务应用程序121和宿主程序122。电子商务应用程序121可包括商户的应用程序,电子商务应用程序所属第一主体,第一主体可包括商户。宿主程序122可包括发卡行的应用程序,宿主程序122所属第二主体,第二主体可包括发卡行。用户终端12还具有第一SDK123和第二SDK124。第一SDK123与电子商务应用程序121集成,第二SDK124与宿主程序122集成。每个电子商务应用程序121可集成有一个第一SDK123,每个宿主程序122可集成有一个第二SDK124。第一SDK123和第二SDK124所属第三主体,第三主体可包括卡组织14和收单机构15。
发卡行13可通过系统与卡组织14的系统对接,以授权资源卡的绑定和资源扣除的渠道,并通过宿主程序122为用户提供支付入口。例如,如图1所示,发卡行13的系统可实现为宿主程序平台16。宿主程序122为发卡行13的前端服务程序,宿主程序平台16为发卡行13的后台系统。宿主程序122和宿主程序平台16所属第二主体。宿主程序平台16可包括多台如服务器等的电子设备,在此并不限定宿主程序平台16中电子设备的类型和数量。用户终端12可通过宿主程序122与宿主程序平台16通信交互。
卡组织14可通过系统提供网络支付服务,并为用户终端提供第一SDK123和第二SDK124。收单机构15可接收、处理线上和线下的支付请 求。其中,卡组织14和收单机构15的功能可集成为一个系统,例如,如图1所示,可通过全网支付平台17实现卡组织14和收单机构15的功能。第一SDK123和第二SDK124为卡组织14和收单机构15的前端服务程序,全网支付平台17为卡组织14和收单机构15的后台系统。第一SDK123、第二SDK124和全网支付平台17所属第三主体。全网支付平台17可包括多台如服务器等的电子设备,在此并不限定全网支付平台17中电子设备的类型和数量。用户终端12可通过第一SDK123、第二SDK124与全网支付平台17通信交互。
下面对本申请提供的支付方法、用户终端、装置、设备、系统及介质依次进行介绍。
本申请第一方面提供一种支付方法,可应用于支付系统,即该支付方法可由支付系统执行。支付系统可包括用户终端、全网支付平台和宿主程序平台,用户终端、全网支付平台和宿主程序平台的具体内容可参见上述实施例中的相关说明,在此不再赘述。图2为本申请第一方面提供的支付方法的一实施例的流程图。如图2所示,该支付方法可包括步骤S201至步骤S205。
在步骤S201中,在电子商务应用程序触发支付的情况下,用户终端调用第一SDK与全网支付平台交互,获取第一宿主程序列表。
电子商务应用程序触发支付可包括用户对用户终端中的电子商务应用程序进行操作,通过电子商务应用程序触发的支付。在触发支付时,用户终端可利用第一SDK能够与全网支付平台通信交互的能力,调用第一SDK与全网支付平台交互,获取第一宿主程序列表。
第一宿主程序列表由全网支付平台提供。第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识。全网支付平台支持的宿主程序可包括向全网支付平台授权的宿主程序,具体地,全网支付平台支持的宿主程序包括向全网支付平台授权开通上述实施例中支付的四方模式的功能的宿主程序。
在一些示例中,第一宿主程序列表可包括全网支付平台支持的所有宿主程序的宿主程序标识。
在另一些示例中,第一宿主程序列表可包括全网支付平台支持的部分宿主程序的宿主程序标识。可有目的性地减少第一宿主程序列表中宿主程序的宿主程序标识的数量,以提高为用户推送宿主程序的精准性,并节省传输资源。
用户终端可通过电子商务应用程序向全网支付平台发送第一支付请求消息。第一支付请求消息包括用户标识,用于指示全网支付平台根据用户标识对应的历史支付数据和/或预存的支付优先级策略生成第一宿主程序列表。响应于第一支付请求消息,全网支付平台根据用户标识对应的历史支付数据和/或预存的支付优先级策略,得到全网支付平台支持的宿主程序的优先级排列顺序,基于优先级由高到低的前N个所述宿主程序的宿主程序标识,生成所述第一宿主程序列表,N为正整数。即第一宿主程序列表包括优先级由高到低排列的N个宿主程序的宿主程序标识。全网支付平台可向用户终端的电子商务应用程序发送第一支付反馈消息,第一支付反馈消息包括第一宿主程序列表。用户终端接收全网支付平台发送的该第一支付反馈消息,以获取第一支付反馈消息中的第一宿主程序列表。
在第一宿主程序列表可包括全网支付平台支持的所有宿主程序的宿主程序标识的情况下,N等于全网支付平台支持的宿主程序的数量。在第一宿主程序列表可包括全网支付平台支持的部分宿主程序的宿主程序标识的情况下,N小于全网支付平台支持的宿主程序的数量。
用户标识用于标识用户。用户标识对应的历史支付数据为用户的历史支付数据。历史支付数据为用户曾经的支付产生的数据。历史支付数据可包括历史支付使用的宿主程序的宿主程序标识、历史支付使用的宿主程序的支付资源量、历史支付使用的宿主程序的支付频率、历史支付使用的宿主程序的支付重要性等,在此并不限定。在一些示例中,根据用户标识对应的历史支付数据,可确定全网支付平台支持的宿主程序的优先级。例如,通过用户标识对应的历史支付数据,可确定用户在历史支付中曾经使用的宿主程序,从而生成第一宿主程序列表,用户在历史支付中曾经使用的宿主程序的优先级高于用户在历史支付中未使用的宿主程序的优先级,第一宿主程序列表可包括全网支付平台支持且用户曾经使用的宿主程序的 宿主程序标识。
支付优先级策略可用于确定全网支付平台支持的宿主程序的优先级,支付优先级策略可根据场景、需求等设置,在此并不限定。在一些示例中,根据支付优先级策略,可确定全网支付平台支持的宿主程序的优先级。例如,支付优先级策略指示全网支付平台支持宿主程序的时间越长,该宿主程序的优先级越高,第一宿主程序列表可包括全网支付平台支持时间最长的N个宿主程序的宿主程序标识。又例如,支付优先级策略指示宿主程序的信用度越高,该宿主程序的优先级越高,第一宿主程序列表可包括全网支付平台信用度最高的N个宿主程序的宿主程序标识。
在一些示例中,可根据用户标识对应的历史支付数据和支付优先级策略,共同确定全网支付平台支持的宿主程序的优先级。支付优先级策略可包括根据历史支付数据确定宿主程序的优先级的策略。例如,历史支付数据包括历史支付使用的宿主程序的支付频率,支付优先级策略指示历史支付使用的宿主程序的支付频率越高,该宿主程序的优先级越高,第一宿主程序列表可包括支付频率最高的N个宿主程序的宿主程序标识。
第一宿主程序列表中宿主程序标识的排列顺序体现宿主程序的优先级,可为后续确定目标宿主程序提供便利,提高确定目标宿主程序的效率。
在步骤S202中,在调用第一SDK在第一宿主程序列表中确定目标宿主程序的情况下,用户终端调起目标宿主程序。
目标宿主程序可为用户终端根据用户的选择确定的宿主程序,也可为第一SDK智能推荐的宿主程序。目标宿主程序为第一宿主程序列表中一个宿主程序标识对应的宿主程序。在确定目标宿主程序的情况下,第一SDK可根据全网支付平台为所述目标宿主程序分配的宿主程序标识,主动调起目标宿主程序,即触发目标宿主程序启动。在调起目标宿主程序后,还可将加密的订单信息一并传输给目标宿主程序,便于目标宿主程序将订单信息传输给第二SDK。
在一些示例中,用户终端可调用第一SDK直接展示第一宿主程序列表,根据用户的选择输入,将第一宿主程序列表中选择输入选定的宿主程 序标识对应的宿主程序确定为目标宿主程序。
在一些示例中,用户终端可调用第一SDK将第一宿主程序列表中宿主程序标识对应的优先级最高的宿主程序确定为目标宿主程序。
在一些示例中,用户终端可调用第一SDK从本地(即用户终端本地)获取第二宿主程序列表;调用第一SDK获取第一宿主程序列表和第二宿主程序列表的交集,展示交集;响应于用户的第一输入,将交集中第一输入指示的宿主程序标识对应的宿主程序确定为目标宿主程序。第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。全网支付平台支持的宿主程序和用户终端具有的宿主程序有可能不同,用户终端可能并不具有第一宿主程序列表中宿主程序标识对应的全网支付平台支持的部分宿主程序,用户终端无法调起自身不具有的宿主程序。为了提高确定目标宿主程序的效率,可取第一宿主程序列表和第二宿主程序列表的交集,该交集包括全网支付平台支持且用户终端具有的宿主程序的宿主程序标识。用户在该交集中选择的目标宿主程序可被用户终端调起。
在一些示例中,用户终端可调用第一SDK从本地获取第二宿主程序列表;调用第一SDK获取第一宿主程序列表和第二宿主程序列表的交集,将交集中宿主程序标识对应的优先级最高的宿主程序确定为目标宿主程序。第二宿主程序列表、交集以及优先级的具体内容可参见上述实施例中的相关说明,在此不再赘述。
用户终端调用第一SDK自动确定目标宿主程序并调起目标宿主程序,可快速、精准地向用户提供支付使用的宿主程序,为用户提供更加快速、便捷的支付服务。
在步骤S203中,用户终端通过目标宿主程序调用第二SDK与全网支付平台交互。
在步骤S204中,全网支付平台与宿主程序平台交互。
在步骤S205中,宿主程序平台执行目标卡的资源扣除,以完成目标卡的支付。
目标卡为与目标宿主程序绑定的一张资源卡。
目标宿主程序被调起后,可再通过目标宿主程序调用第二SDK,这里 调用的第二SDK是与目标宿主程序集成的第二SDK。第二SDK与全网支付平台交互,全网支付平台与宿主程序平台交互,宿主程序平台确定目标卡,执行目标卡的资源扣除,以完成目标卡的支付。与全网支付平台交互的宿主程序平台为与目标宿主程序对应的宿主程序平台。目标卡为与目标宿主程序绑定的一张资源卡。目标卡可为目标宿主程序的支付使用的默认资源卡,也可为用户在与目标宿主程序绑定的资源卡中选择的一张资源卡。目标卡可根据用户的需求切换,在此并不限定。目标卡的确认可根据第二SDK与全网支付平台的交互,以及全网支付平台与宿主程序平台的交互确定。
在本申请实施例中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,第一SDK可与全网支付平台交互,获取包括全网支付平台支持的至少部分宿主程序的宿主程序标识的列表,以使在第一SDK确定目标宿主程序的情况下,用户终端可调起目标宿主程序。目标宿主程序可调用自身集成的第二SDK,第二SDK可与全网支付平台交互,全网支付平台可与目标宿主程序的宿主程序平台交互,以执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。用户终端中电子商务应用程序以及不同的宿主程序都可通过各自集成的SDK与全网支付平台交互,以使全网支付平台再与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一、支付标识统一,实现了对支付的统一管理,降低了支付管理的难度。
不同宿主程序对应的宿主程序平台共享同一个全网支付平台,并通过为不同的宿主程序和电子商务应用程序提供统一的SDK,将支付能力赋予不同的宿主程序和电子商务应用程序,使得不同宿主程序和电子商务应用程序通过各自集成的SDK共享同一个全网支付平台,共享线上和线下的支付受理网络和行业内容,支付管理不再受到支付账户所属发卡行或其他机构的宿主程序的限制,提升了运营效率,降低了运营成本和建设成本,也扩大了支付的受理范围。且用户不需针对不同的宿主程序支付采用不同的操作方式,用户的支付体验得到统一,提高了用户的支付体验。
在一些实施例中,在步骤S201之前,用户终端还可与全网支付平台进行交互,以获取支付对应的订单消息,便于后续发起支付。具体地,响应于用户的第二输入,用户终端通过电子商务应用程序向全网支付平台发起订单请求。订单请求用于向全网支付平台请求订单信息。响应于订单请求,全网支付平台可为电子商务应用程序提供订单信息。订单信息可包括订单编号、订单金额、订单明细等信息,在此并不限定。用户终端的电子商务应用程序接收到订单信息,可根据订单信息显示订单页面。订单页面包括订单信息。响应于用户对于订单页面的第三输入,用户终端触发支付。第三输入为用户的支付触发输入,响应于该输入,用户终端可触发步骤S201。
在一些实施例中,可为具有利用全网支付平台进行支付的功能的宿主程序分配第一标识,以在支付过程中,利用第一标识判断本次支付是否能够采用本申请实施例中的支付方法进行。图3为本申请第一方面提供的支付方法的另一实施例的流程图。图3与图2的不同之处在于,图2中的步骤S203可具体细化为图3中的步骤S2031至步骤S2033,图2中的步骤S204可具体细化为图3中的步骤S2041和步骤S2042,图2中的步骤S205可具体细化为图3中的步骤S2051和步骤S2052,图3中的支付方法还可包括步骤S206和步骤S207。
在步骤S2031中,用户终端调用第二SDK查询目标宿主程序是否具有对应的第一标识。
第一标识用于表征宿主程序中的用户账号具有利用全网支付平台进行支付的功能。第一标识也可表征用户账号在宿主程序与全网支付平台的绑定关系。第一标识可由全网支付平台为宿主程序中的用户账号分配。同一用户可在不同的宿主程序具有不同的第一标识。不同用户在同一宿主程序中具有不同的第一标识。第一标识可实现为字符串、序列号等,在此并不限定。第一标识可具有有效期,在有效期内该第一标识有效,若超出有效期,该第一标识无效,需要重新申请第一标识。有效期可为一固定时长,也可与用户账号的登录情况相关,具体可根据场景、需求等设定,在此并不限定。
在一些示例中,若目标宿主程序具有对应的第一标识,在第一标识申请成功后,用户终端会获取到该第一标识,并将该第一标识存储在用户终端本地。用户终端可调用第二SDK在用户终端本地查询目标宿主程序是否具有对应的第一标识。
在另一些示例中,若目标宿主程序具有对应的第一标识,在第一标识申请成功后,全网支付平台会存储该第一标识。用户终端可调用第二SDK向全网支付平台发起查询请求,由全网支付平台查询目标宿主程序是否具有对应的的第一标识。
在步骤S2032中,在目标宿主程序具有对应的第一标识的情况下,用户终端调用第二SDK向全网支付平台发送第一支付消息。
目标宿主程序具有对应的第一标识,表示目标宿主程序中的该用户账号具有利用全网支付平台进行支付的功能,可以继续支付流程。用户终端调用第二SDK向全网支付平台发送第一支付消息。第一支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在步骤S2041中,全网支付平台向宿主程序平台发送第一支付消息。
全网支付平台根据目标宿主程序对应的第一标识,确定目标宿主程序中用户账号具有利用全网支付平台进行支付的功能,并可根据目标宿主程序的宿主程序标识确定目标宿主程序,从而确定目标宿主程序的宿主程序平台,以向目标宿主程序的宿主程序平台发送第一支付消息。
在步骤S2051中,宿主程序平台根据第一支付消息,确定目标卡,并执行目标卡的资源扣除,完成目标卡的支付。
在一些示例中,第一支付消息可包括卡信息。第一支付消息中的卡信息可指示目标卡。目标宿主程序的宿主程序平台可根据第一支付消息,确定目标卡,执行目标卡的资源扣除,以完成目标卡的支付。
在步骤S206中,在目标宿主程序不具有对应的第一标识的情况下,用户终端调用目标宿主程序通过宿主程序平台向全网支付平台请求目标宿主程序对应的第一标识。
目标宿主程序不具有对应的第一标识,表示目标宿主程序中的该用户账号不具有利用全网支付平台进行支付的功能或目标宿主程序原有的第一 标识已经失效。在这种情况下,用户终端需要再向全网支付平台请求目标宿主程序对应的第一标识。全网支付平台会为目标宿主程序分配第一标识,并通过宿主程序平台向目标宿主程序提供第一标识,即授权给用户终端设备的宿主程序中的用户账号以利用全网支付平台进行支付的功能。
在一些示例中,在登录目标宿主程序的情况下,用户终端调用目标宿主程序向宿主程序平台发送第一标识请求消息。第一标识请求消息包括用户身份信息。用户身份信息包括与用户身份相关的信息,可包括用户的姓名、用户的身份证号、用户的手机号、用户的资源卡卡号等,为了保证数据安全,用户身份信息可为加密信息。
宿主程序平台响应于该第一标识请求消息,向全网支付平台发送第二标识请求消息。第二标识请求消息用于请求第一标识。第二标识请求消息包括用户身份信息和宿主程序标识。这里的宿主程序标识具体为目标宿主程序的宿主程序标识。在一些示例中,第二标识请求消息还可包括目标宿主程序中用户的用户账号。
在步骤S207中,全网支付平台通过宿主程序平台向目标宿主程序提供第一标识。
全网支付平台响应于第二标识请求消息,向目标宿主程序提供第一标识。在一些示例中,在用户开通利用全网支付平台进行支付的功能的用户的身份信息后,全网支付平台可先不为该用户在发卡行或其他机构的用户账号分配第一标识,而是在用户使用发卡行或其他机构的宿主程序进行支付时,再为宿主程序中的用户账号分配第一标识。
在一些示例中,全网支付平台可根据用户身份信息、宿主程序标识和预存的已开通用户身份信息,为目标宿主程序分配第一标识。全网支付平台预存的已开通用户身份信息包括开通利用全网支付平台进行支付的功能的用户的身份信息。为目标宿主程序分配第一标识后,全网支付平台向宿主程序平台发送第二标识反馈消息。第二标识反馈消息包括分配的第一标识。宿主程序平台可根据第二标识反馈消息,向用户终端中的目标宿主程序发送第一标识反馈消息。第一标识反馈消息可包括该第一标识。
全网支付平台可匹配用户身份信息和已开通用户身份信息,根据用户 身份信息和已开通用户身份信息的匹配结果分配第一标识。若用户身份信息和已开通用户身份信息匹配,全网支付平台可分配第一标识,另外还可视用户身份信息具体匹配情况,确定是否需要将目标宿主程序中用户身份信息对应的用户账号与全网支付平台中用户身份信息对应的用户账号已经绑定。若用户身份信息和已开通用户身份信息不匹配,表示用户身份信息还未在全网支付平台中创建用户账号,全网支付平台需要创建全网支付平台中与用户身份信息对应的用户账号。
在一些示例中,用户身份信息包括第一用户唯一标识和第一电话号码,已开通用户身份信息包括第二用户唯一标识和第二电话号码。第一用户唯一标识为用户身份信息中的用户唯一标识。第二用户唯一标识是已开通用户身份信息中的用户唯一标识。用户唯一标识用于标识用户,具有唯一性,不同的用户的用户唯一标识不同。例如,用户唯一标识可包括身份证号,在此并不限定。第一电话号码为用户身份信息中的用户的电话号码,第二电话号码为已开通用户身份信息中的用户的电话号码。
在已开通用户身份信息包括目标第二用户唯一标识的情况下,全网支付平台绑定第一用户账号和第二用户账号,并生成第一标识。
目标第二用户唯一标识为与第一用户唯一标识一致的第二用户唯一标识。对于一个用户而言,该用户在全网支付平台中只有一个用户账号,该用户在不同的宿主程序中具有不同的用户账号。第一用户账号为目标宿主程序中与第一用户唯一标识对应的用户账号,即第一用户账号为第一用户唯一标识表征的用户在目标宿主程序中的用户账号。第二用户账号为与全网支付平台中目标第二用户唯一标识和目标第二电话号码对应的用户账号。目标第二电话号码为与第一电话号码一致的第二电话号码。即第二用户账号可视为目标第二用户唯一标识和目标第二电话号码表征的用户在全网支付平台中的用户账号。
已开通用户身份信息包括开通利用全网支付平台进行支付的功能的用户的身份信息。已开通用户身份信息包括目标第二用户唯一标识,表示第一用户唯一标识表征的用户已经开通利用全网支付平台进行支付的功能,该用户具有全网支付平台的用户账号,将第一用户账号和第二用户账号绑 定。
在已开通用户身份信息只具有一个包括目标第二用户唯一标识的信息的情况下,不管已开通用户身份信息是否包括与第一电话号码一致的第二电话号码,均可将第一用户账号和第二用户账号绑定,即将该用户在目标宿主程序中的用户账号与该用户在全网支付平台中的用户账号绑定,并生成第一标识。
在已开通用户身份信息中具有两个以上包括目标第二用户唯一标识的信息且这两个以上的信息中的第二电话号码不同的情况下,根据这两个以上的信息,选取第二用户唯一标识与第一用户唯一标识一致,且第二电话号码与第一电话号码一致的全网支付平台中的用户账号,将该用户账号作为第二用户账号。绑定第一用户账号和第二用户账号,并生成第一标识。
在已开通用户身份信息不包括目标第二用户唯一标识的情况下,全网支付平台新建第三用户账号,绑定第一用户账户与第三用户账户,并生成第一标识。
第三用户账号为全网支付平台中与第一用户唯一标识对应的用户账号。已开通用户身份信息不包括目标第二用户唯一标识,表示全网支付平台的用户账户中无与第一用户唯一标识对应的用户账号。可针对第一用户唯一标识,新建全网支付平台中第一用户唯一标识表征的用户的用户账号即第三用户账户,绑定第一用户账号和第三用户账号,并生成第一标识。
在一些情况下,已开通用户身份信息不包括目标第二用户唯一标识,但包括与第一电话号码一致的第二电话号码,且在全网支付平台具有与第二电话号码对应的用户账号。在这种情况下,若该第二电话号码已经实名制,基于第一电话号码是否存在错误等支付安全的考虑,不绑定第一用户账户与全网支付平台中第二电话号码对应的用户账号。若该第二电话号码未实名制,可通过第二电话号码的运营商进行实名验证,若运营商处第二电话号码的实名信息与第一用户唯一标识一致,且全网支付平台中第二电话号码对应的用户账户还未与第一用户账户绑定,可绑定第一用户账户与全网支付平台中第二电话号码对应的用户账户,并生成第一标识。
在步骤S2033中,用户终端调用第二SDK向全网支付平台发送第二 支付消息。
第二支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。目标宿主程序对应的第一标识即为上述步骤S207中全网支付平台分配的第一标识。
在步骤S2042中,全网支付平台向宿主程序平台发送第二支付消息。
在步骤S2052中,宿主程序平台根据第二支付消息,确定目标卡,并执行目标卡的资源扣除,完成目标卡的支付。
步骤S2033、步骤S2042和步骤S2052的具体内容可参考步骤S2032、步骤S2041和步骤S2051的相关内容,在此不再赘述。
在一些实施例中,可在步骤S2032之前、步骤S2033之前,对第二SDK的版本、第二SDK的登录情况和/或目标宿主程序中的用户账号、资源转入账号的安全性等进行检测,在检测通过的情况下,再执行步骤S2032、步骤S2033,以保证支付的安全性和可靠性。
对第二SDK的版本的检测可包括以下步骤a1和a2。
a1,用户终端调用目标宿主程序的第二SDK向全网支付平台发送版本判定消息。
版本判定消息可包括目标宿主程序的第二SDK的版本信息。第二SDK的版本信息表征第二SDK的版本。
a2,全网支付平台根据版本判定消息判断第二SDK的版本是否为可用版本,并向目标宿主程序的第二SDK发送版本反馈消息。
全网支付平台可从版本判定消息中获取第二SDK的版本信息,判断第二SDK的版本信息表征的版本是否为全网支付平台的可用版本。全网支付平台通过版本反馈消息向用户终端的第二SDK反馈第二SDK的版本是否为可用版本。版本反馈消息表征第二SDK的版本是否为可用版本。例如,全网支付平台的可用版本包括1.20版本、1.21版本和1.22版本,版本判定消息中第二SDK的版本信息表征1.05版本,则全网支付平台发送的版本反馈消息表征第二SDK的版本不是可用版本。若版本反馈消息表征第二SDK的版本不是可用版本,则不执行步骤S2032、步骤S2033,用户终端可提示用户升级第二SDK。若只对第二SDK的版本进行检测,版 本反馈消息表征第二SDK的版本为可用版本,可执行步骤S2032、步骤S2033。若除了对第二SDK的版本进行检测外,还需进行其他检测,在版本反馈消息表征第二SDK的版本为可用版本的情况下,可根据其他检测的结果,判断是否执行步骤S2032、步骤S2033。
对第二SDK的登录状态的检测可包括以下步骤b1和b2。
b1,用户终端调用目标宿主程序的第二SDK向全网支付平台发送SDK登录判定消息。
SDK登录判定消息可包括用于标识目标宿主程序的第二SDK的信息,例如,SDK登录判定消息可包括第二SDK的SDK标识或目标宿主程序的宿主程序标识。
b2,全网支付平台根据SDK登录判定消息判断第二SDK是否登录,并向目标宿主程序的第二SDK发送SDK登录反馈消息。
全网支付平台可根据SDK登录判定消息中的信息判断第二SDK是否登录。全网支付平台可通过SDK登录反馈消息向用户终端的第二SDK反馈第二SDK是否登录。SDK登录反馈消息可表征第二SDK是否登录。若SDK登录反馈消息表征第二SDK未登录,则不执行步骤S2032、步骤S2033,用户终端可提示用户登录第二SDK。若只对第二SDK的登录状态进行检测,SDK登录反馈消息表征第二SDK已登录,可执行步骤S2032、步骤S2033。若除了对第二SDK的登录状态进行检测外,还需进行其他检测,在SDK登录反馈消息表征第二SDK已登录的情况下,可根据其他检测的结果,判断是否执行步骤S2032、步骤S2033。
对目标宿主程序中的用户账号、资源转入账号的安全性的检测可包括以下步骤c1和c2。
c1、用户终端调用目标宿主程序的第二SDK向全网支付平台发送安全判定消息。
安全判定消息可包括目标宿主程序中的用户账号和本次支付的资源转入账号。
c2、全网支付平台根据安全判定消息判断目标宿主程序中的用户账号和本次支付的资源转入账号是否安全,并向目标宿主程序的第二SDK发 送安全反馈消息。
全网支付平台根据安全判定消息,查找目标宿主程序中的用户账号的历史支付数据以及其他相关数据,还可查找本次支付的资源转入账号的历史支付数据以及其他相关数据,根据目标宿主程序中的用户账号的历史支付数据以及其他相关数据和全网支付平台预设的安全判定策略,确定目标宿主程序中用户账号是否安全,以及,根据本次支付的资源转入账号的历史支付数据以及其他相关数据和全网支付平台预设的安全判定策略,确定本次支付的资源转入账号是否安全。全网支付平台通过安全反馈消息向用户终端的第二SDK反馈目标宿主程序中的用户账号和资源转入账号是否安全。安全反馈消息表征目标宿主程序中的用户账号和资源转入账号是否安全。若安全反馈消息表征目标宿主程序中的用户账号和资源转入账号不安全,则不执行步骤S2032、步骤S2033,用户终端可提示用户中止支付或进行安全性验证。若只对目标宿主程序中的用户账号和资源转入账号的安全性进行检测,安全反馈消息表征目标宿主程序中的用户账号和资源转入账号安全,可执行步骤S2032、步骤S2033。若除了对目标宿主程序中的用户账号和资源转入账号的安全性进行检测外,还需进行其他检测,在安全反馈消息表征目标宿主程序中的用户账号和资源转入账号安全的情况下,可根据其他检测的结果,判断是否执行步骤S2032、步骤S2033。
全网支付平台对用户账号和资源转入账号的安全性进行检测,使得各宿主程序共享安全检测策略,可提升支付行业整体的安全监控处理水平,更好地为支付安全提供保障。
在一些实施例中,为了简化用户开通利用全网支付平台进行支付的功能的流程,可在用户在发卡行开卡或通过用户终端开卡时,直接为用户开通利用全网支付平台进行支付的功能。图4为本申请第一方面提供的支付方法的又一实施例的流程图。图4与图2的不同之处在于,图4所示的支付方法还可包括步骤S208和步骤S209。
在步骤S208中,在用户申请资源卡时,宿主程序平台向全网支付平台发送用户身份信息。
用户申请资源卡时,会在资源卡所属方的宿主程序平台留存用户身份 信息。宿主程序平台会将用户身份信息向全网支付平台发送。用户身份信息的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在步骤S209中,全网支付平台将用户身份信息存储为已开通用户身份信息。
全网支付平台将用户身份信息存储为已开通用户身份信息,以便于在后续终端设备向全网支付平台申请第一标识时,可利用已开通用户身份信息来为用户的宿主程序提供第一标识,具体内容可参见上述实施例中的相关说明,在此不再赘述。
用户开卡即开通用全网支付平台进行支付的功能,能够减少用户开通支付功能的操作,简化开通支付功能的流程,提升功能开通效率和用户体验。
在本申请实施例中,用户终端还可根据支付码、收取码进行支付。
在用户终端采用支付码进行支付的场景中,用户终端可调用第二SDK向全网支付平台发起支付码请求。响应于支付码请求,全网支付平台向第二SDK下发支付码。用户终端可调用第二SDK显示该支付码,以使该支付码被支付受理终端扫描。支付受理终端扫描支付码,向全网支付平台发起支付请求。全网支付平台接收支付受理终端扫描支付码发起的支付请求,与宿主程序平台交互,以完成支付请求指示的支付。支付受理终端可包括销售点(Point of sales,POS)设备等,在此并不限定。在用户终端显示支付码进行支付的场景中,用户终端调用第二SDK请求和显示支付码,使得该支付码被支付受理终端扫描的支付可被全网支付平台统一管理。
在用户终端扫描收取码进行支付的场景中,用户终端调用第二SDK扫描收取码,向全网支付平台发起支付请求。全网支付平台与宿主程序平台交互,以完成支付请求指示的支付。在用户终端扫描收取码实现支付的情况中,用户终端的扫描功能为第二SDK管理的扫描功能,使得扫描收取码的支付可被全网支付平台统一管理。
本申请第二方面提供一种支付方法,应用于用户终端,即该支付方法可由用户终端执行。用户终端的具体内容可参见上述实施例中的相关说 明,在此不再赘述。图5为本申请第二方面提供的支付方法的一实施例的流程图。如图5所示,该支付方法可包括步骤S301至步骤S303。
在步骤S301中,在电子商务应用程序触发支付的情况下,调用第一SDK从全网支付平台获取第一宿主程序列表。
在一些示例中,用户终端可通过电子商务应用程序向全网支付平台发送第一支付请求消息。第一支付请求消息包括用户标识,用于指示全网支付平台根据用户标识对应的历史支付数据和/或预存的支付优先级策略生成第一宿主程序列表。第一宿主程序列表包括优先级由高到低排列的N个宿主程序的宿主程序标识,N为正整数。用户终端接收全网支付平台发送的第一支付反馈消息。第一支付反馈消息包括第一宿主程序列表。
在步骤S302中,在调用第一SDK在第一宿主程序列表中确定目标宿主程序的情况下,调起目标宿主程序。
在一些示例中,在调起目标宿主程序之前,用户终端可调用第一SDK从本地获取第二宿主程序列表;调用第一SDK获取第一宿主程序列表和第二宿主程序列表的交集,展示交集;响应于用户的第一输入,将交集中第一输入指示的宿主程序标识对应的宿主程序确定为目标宿主程序。第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。
在另一些示例中,在调起目标宿主程序之前,用户终端可调用第一SDK从本地获取第二宿主程序列表,调用第一SDK获取第一宿主程序列表和第二宿主程序列表的交集,将交集中宿主程序标识对应的优先级最高的宿主程序确定为目标宿主程序。第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。
在步骤S303中,通过目标宿主程序调用第二SDK与全网支付平台交互,以使全网支付平台与宿主程序平台交互,完成目标卡的支付。
步骤S301至步骤S303的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在本申请实施例中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,第一SDK可与全网支付平台交互,获取包括全网支付平台 支持的至少部分宿主程序的宿主程序标识的列表,以使在第一SDK确定目标宿主程序的情况下,用户终端可调起目标宿主程序。目标宿主程序可调用自身集成的第二SDK,第二SDK可与全网支付平台交互,全网支付平台可与目标宿主程序的宿主程序平台交互,以执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。用户终端中电子商务应用程序以及不同的宿主程序都可通过各自集成的SDK与全网支付平台交互,以使全网支付平台再与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一,实现了对支付的统一管理,降低了支付管理的难度。
不同宿主程序对应的宿主程序平台共享同一个全网支付平台,不同宿主程序通过各自集成的SDK共享同一个全网支付平台,支付管理不再受到支付账户所属发卡行或其他机构的宿主程序的限制,用户支付体验统一,用户不需针对不同的宿主程序支付采用不同的操作方式,提高了用户的支付体验。
在一些实施例中,在步骤S301之前,用户终端还可与全网支付平台进行交互,以获取支付对应的订单消息,便于后续发起支付。用户终端可响应于用户的第二输入,通过电子商务应用程序从全网支付平台获取订单信息;响应于用户对于订单页面的第三输入,触发支付。订单页面包括订单信息。用户终端还可与全网支付平台进行交互,获取订单消息的具体内容可参见上述实施例中相关说明,在此不再赘述。
在一些实施例中,可为具有利用全网支付平台进行支付的功能的宿主程序分配第一标识,以在支付过程中,判断本次支付是否能够采用本申请实施例中的支付方法进行。图6为本申请第二方面提供的支付方法的另一实施例的流程图。图6与图5的不同之处在于,图5中的步骤S303可具体细化为图6中的步骤S3031至步骤S3035。
在步骤S3031中,调用第二SDK查询目标宿主程序是否具有对应的第一标识。
在步骤S3032中,在目标宿主程序具有对应的第一标识的情况下,调用第二SDK向全网支付平台发送第一支付消息,以使全网支付平台向宿 主程序平台发送第一支付消息,由宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。
第一支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在步骤S3033中,在目标宿主程序不具有对应的第一标识的情况下,调用目标宿主程序通过宿主程序平台向全网支付平台请求目标宿主程序对应的第一标识。
在一些示例中,在登录目标宿主程序的情况下,用户终端调用目标宿主程序向宿主程序平台发送第一标识请求消息;用户终端调用目标宿主程序接收宿主程序平台发送的第一标识反馈消息。
第一标识请求消息包括用户身份信息,用于指示宿主程序平台向全网支付平台发送第二标识请求消息。第二标识请求消息用于请求第一标识。第二标识请求消息包括用户身份信息和宿主程序标识。第一标识反馈消息包括第一标识。第一标识反馈信息根据全网支付平台向宿主程序平台发送的第二标识反馈消息生成。第二标识反馈消息包括第一标识。第一标识由全网支付平台根据用户身份信息、宿主程序标识以及预存的已开通用户身份信息得到。
在步骤S3034中,调用目标宿主程序接收全网支付平台通过宿主程序平台分配的目标宿主程序对应的第一标识。
在步骤S3035中,调用第二SDK向全网支付平台发送第二支付消息,以使全网支付平台向宿主程序平台发送第二支付消息,由宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。
第二支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
上述步骤S3031至步骤S3035的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,在上述步骤S3032和步骤S3035之前,可对第二SDK的版本、第二SDK的登录情况和/或目标宿主程序中的用户账号、资源转入账号的安全性等进行检测。
在需要对第二SDK的版本进行检测的示例中,用户终端可调用目标宿主程序的第二SDK向全网支付平台发送版本判定消息;通过目标宿主程序的第二SDK接收全网支付平台发送的版本反馈消息。版本判定消息指示全网支付平台判断第二SDK的版本是否为可用版本。版本反馈消息表征第二SDK的版本是否为可用版本。对第二SDK的版本进行检测的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在需要对第二SDK的登录情况进行检测的示例中,用户终端可调用目标宿主程序的第二SDK向全网支付平台发送SDK登录判定消息;通过目标宿主程序的第二SDK接收全网支付平台发送的SDK登录反馈消息。SDK登录判定消息指示全网支付平台判定第二SDK是否登录。SDK登录反馈消息表征第二SDK的版本是否登录。对第二SDK的登录情况进行检测的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在需要对目标宿主程序中的用户账号、资源转入账号的安全性进行检测的示例中,用户终端可调用目标宿主程序的第二SDK向全网支付平台发送安全判定消息;通过目标宿主程序的第二SDK接收全网支付平台发送的安全反馈消息。安全判定消息指示全网支付平台判断目标宿主程序中的用户账号和本次支付的资源转入账号是否安全。安全反馈消息表征目标宿主程序中的用户账号和资源转入账号是否安全。对目标宿主程序中的用户账号、资源转入账号的安全性进行检测的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,已开通用户身份信息包括用户申请资源卡时宿主程序平台向全网支付平台发送的用户身份信息,具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,用户终端还可根据支付码进行支付。用户终端可调用第二SDK从全网支付平台获取支付码。支付码用于被支付受理终端扫描以向全网支付平台发起支付请求。用户终端根据支付码进行支付的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,用户终端还可根据收取码进行支付。用户终端可调用第二SDK扫描收取码,向全网支付平台发起支付请求。用户终端根据 收取码进行支付的具体内容可参见上述实施例中的相关说明,在此不再赘述。
本申请第三方面提供一种支付方法,应用于全网支付平台,即该支付方法可由全网支付平台执行。全网支付平台的具体内容可参见上述实施例中的相关说明,在此不再赘述。图7为本申请第三方面提供的支付方法的一实施例的流程图。如图7所示,该支付方法可包括步骤S401和步骤S402。
在步骤S401中,在用户终端的电子商务应用程序触发支付的情况下,向用户终端中与电子商务应用程序集成的第一SDK提供第一宿主程序列表。
第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识,用于使用户终端调用第一SDK确定并调起目标宿主程序。
在一些实施例中,全网支付平台可接收用户终端通过电子商务应用发送的第一支付请求消息,第一支付请求消息包括用户标识;根据用户标识对应的历史支付数据和/或预存的支付优先级策略,得到全网支付平台支持的宿主程序的优先级排列顺序;基于优先级由高到低的前N个宿主程序的宿主程序标识,生成第一宿主程序列表,N为正整数;向用户终端的电子商务应用程序发送第一支付反馈消息。第一支付反馈消息包括第一宿主程序列表。
在一些示例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中用户指定的宿主程序标识对应的宿主程序。
在另一些示例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中宿主程序标识对应的优先级最高的宿主程序。
在步骤S402中,与用户终端通过目标宿主程序调用的第二SDK、宿主程序平台交互,完成目标卡的支付。
目标卡为与目标宿主程序绑定的一张资源卡。
步骤S401和步骤S402的具体内容可参见上述实施例中的相关说明, 在此不再赘述。
在本申请实施例中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,全网支付平台可与第一SDK交互,向第一SDK提供包括全网支付平台支持的至少部分宿主程序的宿主程序标识的列表,以使在第一SDK确定目标宿主程序的情况下,用户终端可调起目标宿主程序。全网支付平台可与目标宿主程序自身集成的第二SDK交互,还可与目标宿主程序的宿主程序平台交互,使宿主程序平台执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。全网支付平台可通过用户终端中电子商务应用程序以及不同的宿主程序集成的SDK交互,还可与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一,实现了对支付的统一管理,降低了支付管理的难度。
不同宿主程序对应的宿主程序平台共享同一个全网支付平台,不同宿主程序通过各自集成的SDK共享同一个全网支付平台,支付管理不再受到支付账户所属发卡行或其他机构的宿主程序的限制,用户支付体验统一,用户不需针对不同的宿主程序支付采用不同的操作方式,提高了用户的支付体验。
在一些实施例中,在步骤S401之前,全网支付平台还可与用户终端进行交互,以提供支付对应的订单消息,便于后续发起支付。全网支付平台响应于电子商务应用程序的订单请求,为电子商务应用程序提供订单信息。全网支付平台还可与用户终端进行交互,以提供订单消息的具体内容可参见上述实施例中相关说明,在此不再赘述。
在一些实施例中,可为具有利用全网支付平台进行支付的功能的宿主程序分配第一标识,以在支付过程中,判断本次支付是否能够采用本申请实施例中的支付方法进行。图8为本申请第三方面提供的支付方法的另一实施例的流程图。图8与图7的不同之处在于,图7中的步骤S402可具体细化为图8中的步骤S4021至步骤S4025。
在步骤S4021中,在用户终端调用第二SDK确定目标宿主程序具有对应的第一标识的情况下,接收用户终端调用第二SDK发送的第一支付 消息。
第一标识用于表征宿主程序中的用户账号具有利用全网支付平台进行支付的功能。
在步骤S4022中,向宿主程序平台发送第一支付消息。
第一支付消息指示宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。第一支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在步骤S4023中,在用户终端调用第二SDK确定目标宿主程序不具有对应的第一标识的情况下,通过宿主程序平台向目标宿主程序提供第一标识。
在一些示例中,在登录目标宿主程序的情况下,全网支付平台接收宿主程序平台发送的第二标识请求消息;根据用户身份信息、宿主程序标识和预存的已开通用户身份信息,为目标宿主程序分配第一标识;向宿主程序平台发送第二标识反馈消息,以使宿主程序平台根据第二标识反馈消息向目标宿主程序发送第一标识反馈消息。
第二标识请求消息包括用户身份信息和宿主程序标识。第二标识请求消息根据终端设备调用目标宿主程序发送的第一标识请求消息生成。第一标识请求消息包括用户身份信息。第一标识反馈消息和第二标识反馈消息包括第一标识。
在一些示例中,用户身份信息包括第一用户唯一标识和第一电话号码。已开通用户身份信息包括第二用户唯一标识和第二电话号码。
在已开通用户身份信息包括目标第二用户唯一标识的情况下,全网支付平台绑定第一用户账号和第二用户账号,并生成第一标识。
目标第二用户唯一标识为与第一用户唯一标识一致的第二用户唯一标识。第一用户账号为目标宿主程序中与第一用户唯一标识对应的用户账号。第二用户账号为与全网支付平台中目标第二用户唯一标识和目标第二电话号码对应的用户账号。目标第二电话号码为与第一电话号码一致的第二电话号码。
在已开通用户身份信息不包括目标第二用户唯一标识的情况下,全网 支付平台可新建第三用户账号,绑定第一用户账户与第三用户账户,并生成第一标识。
第三用户账号为全网支付平台中与第一用户唯一标识对应的用户账号。
在步骤S4024中,接收用户终端调用第二SDK发送的第二支付消息。
在步骤S4025中,向宿主程序平台发送第二支付消息。
第二支付消息指示宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。第二支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在上述步骤S4022和步骤S4025之前,可对第二SDK的版本、第二SDK的登录情况和/或目标宿主程序中的用户账号、资源转入账号的安全性等进行检测。
在需要对第二SDK的版本进行检测的示例中,全网支付平台可接收用户终端调用目标宿主程序的第二SDK发送的版本判定消息;根据版本判定消息判断第二SDK的版本是否为可用版本;向目标宿主程序的第二SDK发送版本反馈消息。版本反馈消息表征第二SDK的版本是否为可用版本。对第二SDK的版本进行检测的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在需要对第二SDK的登录情况进行检测的示例中,全网支付平台可接收用户终端调用目标宿主程序的第二SDK发送的SDK登录判定消息;根据SDK登录判定消息判断第二SDK是否登录;向目标宿主程序的第二SDK发送SDK登录反馈消息。SDK登录反馈消息表征第二SDK是否登录。对第二SDK的登录情况进行检测的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在需要对目标宿主程序中的用户账号、资源转入账号的安全性进行检测的示例中,全网支付平台可接收用户终端调用目标宿主程序的第二SDK发送的安全判定消息;根据安全判定消息判断目标宿主程序中的用户账号和本次支付的资源转入账号是否安全;向目标宿主程序的第二SDK发送 安全反馈消息。安全反馈消息表征目标宿主程序中的用户账号和资源转入账号是否安全。对目标宿主程序中的用户账号、资源转入账号的安全性进行检测的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,为了简化用户开通利用全网支付平台进行支付的功能的流程,可在用户在发卡行开卡或通过用户终端开卡时,直接为用户开通利用全网支付平台进行支付的功能。图9为本申请第三方面提供的支付方法的又一实施例的流程图。图9与图7的不同之处在于,图9所示的支付方法还可包括步骤S403和步骤S404。
在步骤S403中,在用户申请资源卡时,接收宿主程序平台发送的用户身份信息。
在步骤S404中,将用户身份信息存储为已开通用户身份信息。
步骤S403和步骤S404的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,用户终端还可根据支付码进行支付。全网支付平台可响应于用户终端调用第二SDK的支付码请求,向第二SDK下发支付码;接收支付受理终端扫描支付码发起的支付请求,与宿主程序平台交互,以完成支付请求指示的支付。用户终端根据支付码进行支付的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,用户终端还可根据收取码进行支付。全网支付平台可接收用户终端调用第二SDK扫描收取码发起的支付请求;与宿主程序平台交互,以完成支付请求指示的支付。用户终端根据收取码进行支付的具体内容可参见上述实施例中的相关说明,在此不再赘述。
本申请第四方面还提供一种支付方法,应用于宿主程序平台,即该支付方法可由宿主程序平台执行。宿主程序平台的具体内容可参见上述实施例中的相关说明,在此不再赘述。图10为本申请第四方面提供的支付方法的一实施例的流程图。如图10所示,该支付方法可包括步骤S501和步骤S502。
在步骤S501中,在用户终端的电子商务应用程序触发支付的情况下,与全网支付平台交互,确定用于支付的目标卡。
目标卡为与目标宿主程序绑定的一张资源卡。目标卡根据用户终端调用的目标宿主程序的第二SDK与全网支付平台交互确定。目标宿主程序为用户终端调用第一SDK在第一宿主程序列表中确定的宿主程序。第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识。
在一些示例中,第一宿主程序列表包括优先级由高到低排列的N个宿主程序的宿主程序标识,N为整数。优先级根据用户终端通过电子商务应用提供的用户标识对应的历史支付数据和/或预存的支付优先级策略确定。
在一些示例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中用户指定的宿主程序标识对应的宿主程序。
在另一些示例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中宿主程序标识对应的优先级最高的宿主程序。
在步骤S502中,执行目标卡的资源扣除,以完成目标卡的支付。
上述步骤S501和步骤S502的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在本申请实施例中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,全网支付平台可与第一SDK交互,向第一SDK提供包括全网支付平台支持的至少部分宿主程序的宿主程序标识的列表,以使在第一SDK确定目标宿主程序的情况下,用户终端可调起目标宿主程序。全网支付平台可与目标宿主程序自身集成的第二SDK交互,还可与目标宿主程序的宿主程序平台交互,使宿主程序平台执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。全网支付平台可通过用户终端中电子商务应用程序以及不同的宿主程序集成的SDK交互,还可与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一,实现了对支付的统一管理,降低了支付管理的难度。
不同宿主程序对应的宿主程序平台共享同一个全网支付平台,不同宿 主程序通过各自集成的SDK共享同一个全网支付平台,支付管理不再受到支付账户所属发卡行或其他机构的宿主程序的限制,用户支付体验统一,用户不需针对不同的宿主程序支付采用不同的操作方式,提高了用户的支付体验。
在一些实施例中,可为具有利用全网支付平台进行支付的功能的宿主程序分配第一标识,以在支付过程中,判断本次支付是否能够采用本申请实施例中的支付方法进行。图11为本申请第四方面提供的支付方法的另一实施例的流程图。图11与图10的不同之处在于,图10中的步骤S501可具体细化为图11中的步骤S5011至步骤S5014。
在步骤S5011中,在用户终端调用第二SDK确定目标宿主程序具有对应的第一标识的情况下,接收用户终端调用第二SDK通过全网支付平台方发送的第一支付消息。
第一支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在步骤S5012中,根据第一支付消息,确定目标卡。
在步骤S5013中,在用户终端调用第二SDK确定目标宿主程序不具有对应的第一标识的情况下,接收用户终端调用第二SDK通过全网支付平台方发送的第二支付消息。
第二支付消息包括目标宿主程序的宿主程序标识和全网支付平台分配的目标宿主程序对应的第一标识。
在一些示例中,在登录目标宿主程序的情况下,宿主程序平台接收用户终端调用目标宿主程序发送的第一标识请求消息,第一标识请求消息包括用户身份信息;响应于第一标识请求消息,向全网支付平台发送第二标识请求消息,第二标识请求消息用于请求第一标识,第二标识请求消息包括用户身份信息和宿主程序标识;接收全网支付平台发送的第二标识反馈消息,第二标识反馈消息包括第一标识,第一标识由全网支付平台根据用户身份信息、宿主程序标识以及预存的已开通用户身份信息得到;根据第二标识反馈消息,向用户终端的目标宿主程序发送第一标识反馈消息,第一标识反馈消息包括第一标识。
在步骤S5014中,根据第二支付消息,确定目标卡。
上述步骤S5011至步骤S5014的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,为了简化用户开通利用全网支付平台进行支付的功能的流程,可在用户在发卡行开卡或通过用户终端开卡时,直接为用户开通利用全网支付平台进行支付的功能。图12为本申请第四方面提供的支付方法的又一实施例的流程图。图12与图10的不同之处在于,图12所示的支付方法还可包括步骤S503。
在步骤S503中,在用户申请资源卡时,向全网支付平台发送用户身份信息,以使全网支付平台将用户身份信息存储为已开通用户身份信息。
上述步骤S503的具体内容可参见上述实施例中的相关说明,在此不再赘述。
为了便于理解,下面分别以支付系统中第一标识申请流程、电子商务应用程序触发支付流程、支付码被扫支付流程和扫描收取码支付流程为示例来说明本申请实施例中支付方法中的部分流程。
图13为本申请实施例中第一标识申请流程的一示例的流程图。如图13所示,第一标识的申请流程涉及终端设备中的宿主程序、第二SDK、宿主程序平台和全网支付平台。第一标识的申请流程可包括步骤S601至步骤S611。
在步骤S601中,宿主程序向宿主程序平台发送第一标识请求消息。
在步骤S602中,宿主程序平台向全网支付平台发送第二标识请求消息。
在步骤S603中,全网支付平台根据第二标识请求消息中的用户身份信息和宿主程序标识,查找宿主程序中用户账户是否具有第一标识,即查找是否具有与宿主程序中用户账户关联的全网支付平台的用户账户。若宿主程序中用户账户不具有第一标识,跳转步骤S604;若宿主程序中用户账户具有第一标识,跳转步骤S609。
在步骤S604中,全网支付平台向宿主程序平台发送无关联账户消息,以通知宿主程序平台全网支付平台不具有与宿主程序中用户账户关联 的全网支付平台的用户账户。
在步骤S605中,宿主程序平台向宿主程序发送账号绑定授权请求,请求用户授权宿主程序中用户账户与全网支付平台的用户账户的绑定。
在步骤S606中,响应于用户的授权输入,宿主程序向宿主程序平台再次发送第一标识请求消息。
用户的授权输入输入的是用户身份信息。这里的第一标识请求消息中的用户身份信息是授权输入的用户身份信息。
在步骤S607中,宿主程序平台向全网支付平台发送第二标识请求消息。
第二标识请求消息包括用户身份信息、宿主程序标识和目标宿主程序中用户的用户账号。
在步骤S608中,全网支付平台根据第二标识请求消息和已开通用户身份信息,进行账号绑定,即对宿主程序中用户账户与全网支付平台的用户账户进行绑定,并生成第一标识。
在步骤S609中,全网支付平台向宿主程序平台发送第二标识反馈消息。
第二标识反馈消息包括第一标识。
在步骤S610中,宿主程序平台向宿主程序发送第一标识反馈消息。
第一标识反馈消息包括第一标识。
在步骤S611中,宿主程序向第二SDK发送第一标识和宿主程序标识。
上述步骤S601至步骤S611中的具体内容可参见上述实施例中的相关说明,在此不再赘述。
图14为本申请实施例中电子商务应用程序触发支付流程的一示例的流程图。如图14所示,电子商务应用程序触发支付流程可涉及用户终端中的电子商务应用程序、第一SDK、宿主程序、第二SDK、宿主程序平台和全网支付平台。宿主程序指的是目标宿主程序,对应地,宿主程序平台指的是目标宿主程序的宿主程序平台。全网支付平台可包括渠道子平台和支付子平台,渠道子平台主要用于管理全网支付平台支持的各宿主程序 及宿主程序平台的相关信息,支付子平台用于管理各SDK的相关信息。电子商务应用程序触发支付流程可包括步骤S701至步骤S719。
在步骤S701中,响应于用户对用户终端中电子商务应用程序的第二输入,用户终端通过电子商务应用程序向全渠道子平台发送订单请求。
在步骤S702中,渠道子平台响应于订单请求,生成订单信息,并向用户终端中的电子商务应用程序反馈订单信息。
在步骤S703中,用户终端中调用电子商务应用程序显示订单页面,订单页面包括订单信息。
在步骤S704中,用户终端中调用电子商务应用程序触发支付,向渠道子平台发送第一支付请求消息。
在步骤S705中,渠道子平台响应于第一支付请求信息,生成第一宿主程序列表。
在步骤S706中,渠道子平台向电子商务应用程序反馈第一支付反馈消息。第一支付反馈消息包括第一宿主程序列表。
在步骤S707中,电子商务应用程序调用第一SDK根据第一宿主程序列表确定目标宿主程序,调起目标宿主程序。
在步骤S708中,目标宿主程序调起目标宿主程序的第二SDK。
在步骤S709中,用户终端中调用第二SDK检查用户登录状态。
在步骤S710中,用户终端中调用第二SDK向支付子平台发送版本判定消息和SDK登录判定消息。
在步骤S711中,支付子平台根据版本判定消息和SDK登录判定消息,判断第二SDK的版本是否为可用版本以及第二SDK是否登录,并向第二SDK反馈版本反馈消息和SDK登录反馈消息。
在步骤S712中,用户终端中调用第二SDK向渠道子平台发送安全判定消息。
在步骤S713中,渠道子平台根据安全判定消息,判断目标宿主程序中的用户账号和本次支付的资源转入账号是否安全,并向第二SDK反馈安全反馈消息。
在步骤S714中,用户终端调用第二SDK展示支付详情,向用户请求 验证。
在步骤S715中,用户验证成功后,第二SDK向渠道子平台发送支付请求。
在步骤S716中,渠道子平台向宿主程序平台发送支付请求。
在步骤S717中,宿主程序平台根据支付请求,在用户的目标卡中扣除资源。
在步骤S718中,宿主程序平台向渠道子平台反馈支付结果。
在步骤S719中,渠道子平台向第二SDK发送支付结果。
上述步骤S701至步骤S719的具体内容可参见上述实施例中的相关说明,在此不再赘述。
支付码被扫支付根据模式可分为应用程序前置模式的支付码被扫支付和资源卡前置模式的支付码被扫支付。下面分别对这两个模式的支付码被扫支付进行举例说明。
图15为本申请实施例提供的应用程序前置模式的支付码被扫支付流程的一示例的流程图。如图15所示,该支付码被扫支付流程涉及用户终端中宿主程序的第二SDK、全网支付平台、宿主程序平台和资源收取方系统。全网支付平台可包括码管理子平台,码管理子平台负责支付码的管理以及全网支付平台的附加信息的管理。资源收取方系统为支付中的资源转入账户的所属方系统,可包括支付受理终端设备即其他设备等。应用程序前置模式的支付码被扫支付流程可包括步骤S801a至步骤S811a。
在步骤S801a中,用户终端调用宿主程序的第二SDK向码管理子平台发送支付码请求。
在步骤S802a中,码管理子平台响应于支付码请求,生成支付标识即支付Token,将支付Token转换为支付码,并向第二SDK下发支付码。
在步骤S803a中,用户终端调用第二SDK显示支付码。
在步骤S804a中,资源收取方系统扫描支付码,向码管理子平台发送支付请求。
在步骤S805a中,码管理子平台向第二SDK发送附加处理请求。
附加处理请求可包括与支付相关的附加信息。附加信息可包括优惠信 息、活动信息等。
在步骤S806a中,用户终端调用第二SDK向码管理子平台发送附加处理结果通知。
附加处理结果通知包括表征用户选择附加信息的情况的信息。
在步骤S807a中,码管理子平台向宿主程序平台发送支付请求。
在步骤S808a中,宿主程序平台根据支付请求,在用户的目标卡中扣除资源。
在步骤S809a中,宿主程序平台向码管理子平台反馈支付结果。
在步骤S810a中,码管理子平台向资源收取方系统发送支付结果。
在步骤S811a中,码管理子平台向第二SDK发送支付结果。
上述步骤S801a至步骤S811a的具体内容可参见上述实施例中的相关说明,在此不再赘述。
图16为本申请实施例提供的资源卡前置模式的支付码被扫支付流程的一示例的流程图。如图16所示,该支付码被扫支付流程涉及用户终端中宿主程序的第二SDK、全网支付平台、宿主程序平台和资源收取方系统。全网支付平台可包括码管理子平台,码管理子平台负责支付码的管理以及全网支付平台的附加信息的管理。宿主程序平台包括宿主程序子平台和资源卡前置子平台,宿主程序子平台负责与宿主程序交互,资源卡前置子平台负责卡中资源的扣除以及转入。资源收取方系统为支付中的资源转入账户的所属方系统,可包括支付受理终端设备即其他设备等。资源卡前置模式的支付码被扫支付流程可包括步骤S801b至步骤S812b。
在步骤S801b中,用户终端调用宿主程序的第二SDK向码管理子平台发送支付码请求。
在步骤S802b中,码管理子平台响应于支付码请求,生成支付标识即支付Token,将支付Token转换为支付码,并向第二SDK下发支付码。
在步骤S803b中,用户终端调用第二SDK显示支付码。
在步骤S804b中,资源收取方系统扫描支付码,向码管理子平台发送支付请求。
在步骤S805b中,码管理子平台向第二SDK发送附加处理请求。
附加处理请求可包括与支付相关的附加信息。附加信息可包括优惠信息、活动信息等。
在步骤S806b中,用户终端调用第二SDK向码管理子平台发送附加处理结果通知。
附加处理结果通知包括表征用户选择附加信息的情况的信息。
在步骤S807b中,码管理子平台向资源卡前置子平台发送支付请求。
在步骤S808b中,资源卡前置子平台根据支付请求,在用户的目标卡中扣除资源。
在步骤S809b中,资源卡前置子平台向码管理子平台反馈支付结果。
在步骤S810b中,码管理子平台向资源收取方系统发送支付结果。
在步骤S811b中,码管理子平台向第二SDK发送支付结果。
在步骤S812b中,码管理子平台向宿主程序子平台发送支付结果。
上述步骤S801b至步骤S812b的具体内容可参见上述实施例中的相关说明,在此不再赘述。
扫描收取码支付根据模式可分为应用程序前置模式的扫描收取码支付和资源卡前置模式的扫描收取码支付。下面分别对这两个模式的扫描收取码支付进行举例说明。
图17为本申请实施例提供的应用程序前置模式的扫描收取码支付流程的一示例的流程图。如图17所示,该扫描收取码支付流程涉及用户终端中宿主程序的第二SDK、全网支付平台、宿主程序平台和资源收取方系统。全网支付平台可包括码管理子平台,码管理子平台负责收取码的管理。资源收取方系统为支付中的资源转入账户的所属方系统。应用程序前置模式的扫描收取码支付流程可包括步骤S801c至步骤S806c。
在步骤S801c中,用户终端调用宿主程序的第二SDK扫描收取码,向码管理子平台发送支付请求。
在步骤S802c中,码管理子平台响应于支付请求,向宿主程序平台发送资源扣除请求。资源扣除请求可包括资源扣除方信息、资源扣除量、资源转入账户所属方代码、资源转入账户所属方类别、资源转入账户所属方名称、附加信息等。附加信息可包括优惠信息、活动信息等。
在步骤S803c中,宿主程序平台响应于资源扣除请求,在用户的目标卡中扣除资源。
在步骤S804c中,宿主程序平台向码管理子平台发送资源扣除结果。
资源扣除结果表征扣款成功或扣款失败。
在步骤S805c中,码管理子平台向第二SDK发送资源扣除结果。
在步骤S806c中,码管理子平台向资源收取方系统发送支付结果。
支付结果可包括资源扣除方信息、资源扣除量、资源转入账户所属方代码、资源转入账户所属方类别、资源转入账户所属方名称、附加信息等。
上述步骤S801c至步骤S806c的具体内容可参见上述实施例中的相关说明,在此不再赘述。
图18为本申请实施例提供的资源卡前置模式的扫描收取码支付流程的一示例的流程图。如图18所示,该扫描收取码支付流程涉及用户终端中宿主程序的第二SDK、全网支付平台、宿主程序平台和资源收取方系统。全网支付平台可包括码管理子平台,码管理子平台负责支付码的管理。宿主程序平台包括宿主程序子平台和资源卡前置子平台,宿主程序子平台负责与宿主程序交互,资源卡前置子平台负责卡中资源的扣除以及转入。资源收取方系统为支付中的资源转入账户的所属方系统。应用程序前置模式的扫描收取码支付流程可包括步骤S801d至步骤S807d。
在步骤S801d中,用户终端调用宿主程序的第二SDK扫描收取码,向码管理子平台发送支付请求。
在步骤S802d中,码管理子平台响应于支付请求,向资源卡前置子平台发送资源扣除请求。
在步骤S803d中,资源卡前置子平台响应于资源扣除请求,在用户的目标卡中扣除资源。
在步骤S804d中,资源卡前置子平台向码管理子平台发送资源扣除结果。
在步骤S805d中,码管理子平台向第二SDK发送资源扣除结果。
在步骤S806d中,码管理子平台向资源收取方系统发送资源扣除结 果。
在步骤S807d中,码管理子平台向宿主程序子平台发送资源扣除结果。
上述步骤S801d至步骤S807d的具体内容可参见上述实施例中的相关说明,在此不再赘述。
本申请第五方面提供一种用户终端,该用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。图19为本申请第五方面提供的用户终端的一实施例的结构示意图。如图19所示,该用户终端900包括调用模块901和交互模块902。
调用模块901可用于在电子商务应用程序触发支付的情况下,调用第一SDK利用交互模块902从全网支付平台获取第一宿主程序列表,以及,还用于在调用第一SDK在第一宿主程序列表中确定目标宿主程序的情况下,调起目标宿主程序。
第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识。
调用模块901还可用于通过目标宿主程序调用第二SDK利用交互模块902与全网支付平台交互,以使全网支付平台与宿主程序平台交互,完成目标卡的支付。
目标卡为与目标宿主程序绑定的一张资源卡。
在本申请实施例中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,第一SDK可与全网支付平台交互,获取包括全网支付平台支持的至少部分宿主程序的宿主程序标识的列表,以使在第一SDK确定目标宿主程序的情况下,用户终端可调起目标宿主程序。目标宿主程序可调用自身集成的第二SDK,第二SDK可与全网支付平台交互,全网支付平台可与目标宿主程序的宿主程序平台交互,以执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。用户终端中电子商务应用程序以及不同的宿主程序都可通过各自集成的SDK与全网支付平台交互,以使全网支 付平台再与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一,实现了对支付的统一管理,降低了支付管理的难度。
不同宿主程序对应的宿主程序平台共享同一个全网支付平台,不同宿主程序通过各自集成的SDK共享同一个全网支付平台,支付管理不再受到支付账户所属发卡行或其他机构的宿主程序的限制,用户支付体验统一,用户不需针对不同的宿主程序支付采用不同的操作方式,提高了用户的支付体验。
在一些实施例中,交互模块902可包括发送单元和接收单元。
调用模块901可用于通过电子商务应用程序利用发送单元向全网支付平台发送第一支付请求消息。
第一支付请求消息包括用户标识,用于指示全网支付平台根据用户标识对应的历史支付数据和/或预存的支付优先级策略生成第一宿主程序列表。第一宿主程序列表包括优先级由高到低排列的N个宿主程序的宿主程序标识,N为正整数。
接收单元可用于接收全网支付平台发送的第一支付反馈消息。
第一支付反馈消息包括第一宿主程序列表。
在一些实施例中,上述调用模块901还可用于:调用第一SDK从本地获取第二宿主程序列表,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识;调用第一SDK获取第一宿主程序列表和第二宿主程序列表的交集,展示交集;响应于用户的第一输入,将交集中第一输入指示的宿主程序标识对应的宿主程序确定为目标宿主程序。
在一些实施例中,上述调用模块901还可用于:调用第一SDK从本地获取第二宿主程序列表,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识;调用第一SDK获取第一宿主程序列表和第二宿主程序列表的交集,将交集中宿主程序标识对应的优先级最高的宿主程序确定为目标宿主程序。
在一些实施例中,上述调用模块901可用于调用第二SDK查询目标宿主程序是否具有对应的第一标识,第一标识用于表征宿主程序中的用户 账号具有利用全网支付平台进行支付的功能。
调用模块901可用于在目标宿主程序具有对应的第一标识的情况下,调用第二SDK利用发送单元向全网支付平台发送第一支付消息,以使全网支付平台向宿主程序平台发送第一支付消息,由宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。第一支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在一些实施例中,调用模块901可用于在目标宿主程序不具有对应的第一标识的情况下,调用目标宿主程序通过宿主程序平台利用交互模块902向全网支付平台请求目标宿主程序对应的第一标识。
调用模块901还可用于调用目标宿主程序利用接收单元接收全网支付平台通过宿主程序平台分配的目标宿主程序对应的第一标识。
调用模块901还可用于调用第二SDK利用发送单元向全网支付平台发送第二支付消息,以使全网支付平台向宿主程序平台发送第二支付消息,由宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。第二支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在一些实施例中,
调用模块901可用于在登录目标宿主程序的情况下,调用目标宿主程序利用发送单元向宿主程序平台发送第一标识请求消息。第一标识请求消息包括用户身份信息,用于指示宿主程序平台向全网支付平台发送第二标识请求消息。第二标识请求消息用于请求第一标识。第二标识请求消息包括用户身份信息和宿主程序标识。
调用模块901可用于调用目标宿主程序利用接收单元接收宿主程序平台发送的第一标识反馈消息。第一标识反馈消息包括第一标识。第一标识反馈信息根据全网支付平台向宿主程序平台发送的第二标识反馈消息生成。第二标识反馈消息包括第一标识。第一标识由全网支付平台根据用户身份信息、宿主程序标识以及预存的已开通用户身份信息得到。
在一些示例中,已开通用户身份信息包括用户申请资源卡时宿主程序平台向全网支付平台发送的用户身份信息。
在一些实施例中,调用模块901还可用于调用目标宿主程序的第二SDK利用发送单元向全网支付平台发送版本判定消息。版本判定消息指示全网支付平台判断第二SDK的版本是否为可用版本。
调用模块901还可用于通过目标宿主程序的第二SDK利用接收单元接收全网支付平台发送的版本反馈消息。版本反馈消息表征第二SDK的版本是否为可用版本
在一些实施例中,调用模块901还可用于调用目标宿主程序的第二SDK利用发送单元向全网支付平台发送SDK登录判定消息。SDK登录判定消息指示全网支付平台判定第二SDK是否登录。
调用模块901还可用于通过目标宿主程序的第二SDK利用接收单元接收全网支付平台发送的SDK登录反馈消息。SDK登录反馈消息表征第二SDK的版本是否登录。
在一些实施例中,调用模块901还可用于调用目标宿主程序的第二SDK利用发送单元向全网支付平台发送安全判定消息。安全判定消息指示全网支付平台判断目标宿主程序中的用户账号和本次支付的资源转入账号是否安全。
调用模块901还可用于通过目标宿主程序的第二SDK利用接收单元接收全网支付平台发送的安全反馈消息。安全反馈消息表征目标宿主程序中的用户账号和资源转入账号是否安全。
在一些实施例中,用户终端900还包括处理模块。
调用模块901还可用于响应于用户的第二输入,通过电子商务应用程序利用交互模块902从全网支付平台获取订单信息。
处理模块可用于响应于用户对于订单页面的第三输入,触发支付。订单页面包括订单信息。
在一些实施例中,调用模块901还可用于调用第二SDK通过交互模块从全网支付平台获取支付码,支付码用于被支付受理终端扫描以向全网支付平台发起支付请求;
在一些实施例中,调用模块901还可用于调用第二SDK扫描收取码。交互模块902还可用于向全网支付平台发起支付请求。
本申请第六方面提供一种支付管理装置,该支付管理装置为上述实施例中全网支付平台中的装置。图20为本申请第六方面提供的支付管理装置的一实施例的结构示意图。如图20所示,该支付管理装置1000包括交互模块1001,交互模块1001可包括发送单元10011。在一些示例中,交互模块1001还可包括接收单元10012。
发送单元10011可用于在用户终端的电子商务应用程序触发支付的情况下,向用户终端中与电子商务应用程序集成的第一软件开发工具包SDK提供第一宿主程序列表。
用户终端具有电子商务应用程序、第一SDK、宿主程序以及与宿主程序集成的第二SDK。第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识,用于使用户终端调用第一SDK确定并调起目标宿主程序。
交互模块1001可用于与用户终端通过目标宿主程序调用的第二SDK、宿主程序平台交互,完成目标卡的支付。
目标卡为与目标宿主程序绑定的一张资源卡。
在本申请实施例中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,全网支付平台可与第一SDK交互,向第一SDK提供包括全网支付平台支持的至少部分宿主程序的宿主程序标识的列表,以使在第一SDK确定目标宿主程序的情况下,用户终端可调起目标宿主程序。全网支付平台可与目标宿主程序自身集成的第二SDK交互,还可与目标宿主程序的宿主程序平台交互,使宿主程序平台执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。全网支付平台可通过用户终端中电子商务应用程序以及不同的宿主程序集成的SDK交互,还可与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一,实现了对支付的统一管理,降低了支付管理的难度。
不同宿主程序对应的宿主程序平台共享同一个全网支付平台,不同宿主程序通过各自集成的SDK共享同一个全网支付平台,支付管理不再受到支付账户所属发卡行或其他机构的宿主程序的限制,用户支付体验统 一,用户不需针对不同的宿主程序支付采用不同的操作方式,提高了用户的支付体验。
在一些实施例中,支付管理装置1000还可包括处理模块。图21为本申请第六方面提供的支付管理装置的另一实施例的结构示意图。图21与图20的不同之处在于,图21所示的支付管理装置1000还可包括处理模块1002。
接收单元10012可用于接收用户终端通过电子商务应用发送的第一支付请求消息,第一支付请求消息包括用户标识,
处理模块1002可用于:根据用户标识对应的历史支付数据和/或预存的支付优先级策略,得到全网支付平台支持的宿主程序的优先级排列顺序;基于优先级由高到低的前N个宿主程序的宿主程序标识,生成第一宿主程序列表,N为正整数。
发送单元10011可用于向用户终端的电子商务应用程序发送第一支付反馈消息,第一支付反馈消息包括第一宿主程序列表。
在一些实施例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中用户指定的宿主程序标识对应的宿主程序。
在一些实施例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中宿主程序标识对应的优先级最高的宿主程序。
在一些实施例中,接收单元10012可用于在用户终端调用第二SDK确定目标宿主程序具有对应的第一标识的情况下,接收用户终端调用第二SDK发送的第一支付消息。第一标识用于表征宿主程序中的用户账号具有利用全网支付平台进行支付的功能。
发送单元10011可用于向宿主程序平台发送第一支付消息。第一支付消息指示宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。第一支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在一些实施例中,发送单元10011可用于在用户终端调用第二SDK 确定目标宿主程序不具有对应的第一标识的情况下,通过宿主程序平台向目标宿主程序提供第一标识。
接收单元10012可用于接收用户终端调用第二SDK发送的第二支付消息。
发送单元10011可用于向宿主程序平台发送第二支付消息。
第二支付消息指示宿主程序平台执行目标卡的资源扣除,完成目标卡的支付。第二支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
在一些实施例中,接收单元10012可用于在登录目标宿主程序的情况下,接收宿主程序平台发送的第二标识请求消息。
第二标识请求消息包括用户身份信息和宿主程序标识。第二标识请求消息根据终端设备调用目标宿主程序发送的第一标识请求消息生成。第一标识请求消息包括用户身份信息。
处理模块1002可用于根据用户身份信息、宿主程序标识和预存的已开通用户身份信息,为目标宿主程序分配第一标识。
发送单元10011可用于向宿主程序平台发送第二标识反馈消息,以使宿主程序平台根据第二标识反馈消息向目标宿主程序发送第一标识反馈消息。
第一标识反馈消息和第二标识反馈消息包括第一标识。
在一些实施例中,用户身份信息包括第一用户唯一标识和第一电话号码,已开通用户身份信息包括第二用户唯一标识和第二电话号码。
处理模块1002还可用于在已开通用户身份信息包括目标第二用户唯一标识的情况下,绑定第一用户账号和第二用户账号,并生成第一标识。
目标第二用户唯一标识为与第一用户唯一标识一致的第二用户唯一标识。第一用户账号为目标宿主程序中与第一用户唯一标识对应的用户账号。第二用户账号为与全网支付平台中目标第二用户唯一标识和目标第二电话号码对应的用户账号。目标第二电话号码为与第一电话号码一致的第二电话号码。
处理模块1002还可用于在已开通用户身份信息不包括目标第二用户 唯一标识的情况下,新建第三用户账号,绑定第一用户账户与第三用户账户,并生成第一标识。
第三用户账号为全网支付平台中与第一用户唯一标识对应的用户账号。
在一些实施例中,接收单元10012还可用于接收用户终端调用目标宿主程序的第二SDK发送的版本判定消息。
处理模块1002还可用于根据版本判定消息判断第二SDK的版本是否为可用版本。
发送单元10011还可用于向目标宿主程序的第二SDK发送版本反馈消息,版本反馈消息表征第二SDK的版本是否为可用版本。
在一些实施例中,接收单元10012还可用于接收用户终端调用目标宿主程序的第二SDK发送的SDK登录判定消息。
处理模块1002还可用于根据SDK登录判定消息判断第二SDK是否登录。
发送单元10011还可用于向目标宿主程序的第二SDK发送SDK登录反馈消息,SDK登录反馈消息表征第二SDK是否登录。
在一些实施例中,接收单元10012还可用于接收用户终端调用目标宿主程序的第二SDK发送的安全判定消息。
处理模块1002还可用于根据安全判定消息判断目标宿主程序中的用户账号和本次支付的资源转入账号是否安全。
发送模块10011还可用于向目标宿主程序的第二SDK发送安全反馈消息,安全反馈消息表征目标宿主程序中的用户账号和资源转入账号是否安全。
在一些实施例中,接收单元10012还可用于在用户申请资源卡时,接收宿主程序平台发送的用户身份信息。
处理模块1002还可用于将用户身份信息存储为已开通用户身份信息。
在一些实施例中,发送单元10011还可用于响应于电子商务应用程序的订单请求,为电子商务应用程序提供订单信息。
在一些实施例中,发送单元10011还可用于响应于用户终端调用第二SDK的支付码请求,向第二SDK下发支付码。
接收单元10012还可用于接收支付受理终端扫描支付码发起的支付请求,与宿主程序平台交互,以完成支付请求指示的支付。
在一些实施例中,接收单元10012还可用于接收用户终端调用第二SDK扫描收取码发起的支付请求。
交互模块1001可用于与宿主程序平台交互,以完成支付请求指示的支付。
本申请第七方面提供一种后台服务装置,该后台服务装置为上述实施例中宿主程序平台中的装置。图22为本申请第七方面提供的后台服务装置的一实施例的结构示意图。如图22所示,该后台服务装置1100包括交互模块1101和执行模块1102。
交互模块1101可用于在用户终端的电子商务应用程序触发支付的情况下,与全网支付平台交互,确定用于支付的目标卡。
用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。目标卡为与目标宿主程序绑定的一张资源卡。目标卡根据用户终端调用的目标宿主程序的第二SDK与全网支付平台交互确定。目标宿主程序为用户终端调用第一SDK在第一宿主程序列表中确定的宿主程序。第一宿主程序列表包括全网支付平台支持的至少部分宿主程序的宿主程序标识。
在一些示例中,第一宿主程序列表包括优先级由高到低排列的N个宿主程序的宿主程序标识,N为整数,优先级根据用户终端通过电子商务应用提供的用户标识对应的历史支付数据和/或预存的支付优先级策略确定。
执行模块1102可用于执行目标卡的资源扣除,以完成目标卡的支付。
在本申请实施例中,用户终端具有电子商务应用程序、与电子商务应用程序集成的第一SDK、宿主程序以及与宿主程序集成的第二SDK。在支付过程中,全网支付平台可与第一SDK交互,向第一SDK提供包括全网支付平台支持的至少部分宿主程序的宿主程序标识的列表,以使在第一 SDK确定目标宿主程序的情况下,用户终端可调起目标宿主程序。全网支付平台可与目标宿主程序自身集成的第二SDK交互,还可与目标宿主程序的宿主程序平台交互,使宿主程序平台执行与目标宿主程序绑定的目标卡的资源扣除,完成支付。全网支付平台可通过用户终端中电子商务应用程序以及不同的宿主程序集成的SDK交互,还可与不同的应用程序对应的宿主程序后台交互,使支付过程中不同发卡行以及其他机构之间支付技术规范统一,实现了对支付的统一管理,降低了支付管理的难度。
不同宿主程序对应的宿主程序平台共享同一个全网支付平台,不同宿主程序通过各自集成的SDK共享同一个全网支付平台,支付管理不再受到支付账户所属发卡行或其他机构的宿主程序的限制,用户支付体验统一,用户不需针对不同的宿主程序支付采用不同的操作方式,提高了用户的支付体验。
在一些实施例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中用户指定的宿主程序标识对应的宿主程序。
在一些实施例中,第二宿主程序列表包括用户终端具有的宿主程序的宿主程序标识。目标宿主程序为第一宿主程序列表和第二宿主程序列表的交集中宿主程序标识对应的优先级最高的宿主程序。
在一些实施例中,交互模块1101可用于在用户终端调用第二SDK确定目标宿主程序具有对应的第一标识的情况下,接收用户终端调用第二SDK通过全网支付平台方发送的第一支付消息。
第一支付消息包括目标宿主程序的宿主程序标识和目标宿主程序对应的第一标识。
执行模块1102可用于根据第一支付消息,确定目标卡。
在一些实施例中,交互模块1101可用于在用户终端调用第二SDK确定目标宿主程序不具有对应的第一标识的情况下,接收用户终端调用第二SDK通过全网支付平台方发送的第二支付消息。
第二支付消息包括目标宿主程序的宿主程序标识和全网支付平台分配的目标宿主程序对应的第一标识;
执行模块1102可用于根据第二支付消息,确定目标卡。
在一些实施例中,交互模块1101还可用于在登录目标宿主程序的情况下,接收用户终端调用目标宿主程序发送的第一标识请求消息。
第一标识请求消息包括用户身份信息。
交互模块1101还可用于响应于第一标识请求消息,向全网支付平台发送第二标识请求消息。
第二标识请求消息用于请求第一标识。第二标识请求消息包括用户身份信息和宿主程序标识。
交互模块1101还可用于接收全网支付平台发送的第二标识反馈消息。
第二标识反馈消息包括第一标识。第一标识由全网支付平台根据用户身份信息、宿主程序标识以及预存的已开通用户身份信息得到。
交互模块1101还可用于根据第二标识反馈消息,向用户终端的目标宿主程序发送第一标识反馈消息。
第一标识反馈消息包括第一标识。
在一些实施例中,交互模块1101还可用于在用户申请资源卡时,向全网支付平台发送用户身份信息,以使全网支付平台将用户身份信息存储为已开通用户身份信息。
本申请第八方面还提供了一种用户终端。图23为本申请第八方面提供的用户终端的一实施例的结构示意图。如图23所示,用户终端1200包括存储器1201、处理器1202及存储在存储器1201上并可在处理器1202上运行的计算机程序。
在一些示例中,上述处理器1202可以包括中央处理器(CPU),或者特定集成电路(Application Specific Integrated Circuit,ASIC),或者可以被配置成实施本申请实施例的一个或多个集成电路。
存储器1201可包括只读存储器(Read-Only Memory,ROM),随机存取存储器(Random Access Memory,RAM),磁盘存储介质设备,光存储介质设备,闪存设备,电气、光学或其他物理/有形的存储器存储设备。因此,通常,存储器包括一个或多个编码有包括计算机可执行指令的 软件的有形(非暂态)计算机可读存储介质(例如,存储器设备),并且当该软件被执行(例如,由一个或多个处理器)时,其可操作来执行参考根据本申请第二方面的实施例中支付方法所描述的操作。
处理器1202通过读取存储器1201中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序,以用于实现上述第二方面实施例中的支付方法。
在一些示例中,用户终端1200还可包括通信接口1203和总线1204。其中,如图23所示,存储器1201、处理器1202、通信接口1203通过总线1204连接并完成相互间的通信。
通信接口1203,主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口1203接入输入设备和/或输出设备。
总线1204包括硬件、软件或两者,将用户终端1200的部件彼此耦接在一起。举例来说而非限制,总线1204可包括加速图形端口(Accelerated Graphics Port,AGP)或其他图形总线、增强工业标准架构(Enhanced Industry Standard Architecture,EISA)总线、前端总线(Front Side Bus,FSB)、超传输(Hyper Transport,HT)互连、工业标准架构(Industry Standard Architecture,ISA)总线、无限带宽互连、低引脚数(Low pin count,LPC)总线、存储器总线、微信道架构(Micro Channel Architecture,MCA)总线、外围组件互连(Peripheral Component Interconnect,PCI)总线、PCI-Express(PCI-E)总线、串行高级技术附件(Serial Advanced Technology Attachment,SATA)总线、视频电子标准协会局部(Video Electronics Standards Association Local Bus,VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下,总线1204可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线,但本申请考虑任何合适的总线或互连。
本申请第九方面提供一种支付管理设备,支付管理设备为上述实施例中全网支付平台中的设备。支付管理设备可包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。在一些示例中,支付管理设 备还可包括通信接口和总线。存储器、处理器、通信接口可通过总线连接并完成相互间的通信。
存储器、处理器、通信接口和总线的连接关系以及实例描述可参见上述用户终端实施例中的相关说明,在此不再赘述。支付管理设备与用户终端实施例的不同之处在于,处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序,以用于实现上述第三方面实施例中的支付方法。具体地,存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如,存储器设备),并且当该软件被执行(例如,由一个或多个处理器)时,其可操作来执行参考根据本申请第三方面的实施例中支付方法所描述的操作。
本申请第十方面提供一种后台服务设备,后台服务器设备为上述实施例中宿主程序平台中的设备。后台服务设备可包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。在一些示例中,支付管理设备还可包括通信接口和总线。存储器、处理器、通信接口可通过总线连接并完成相互间的通信。
存储器、处理器、通信接口和总线的连接关系以及实例描述可参见上述用户终端实施例中的相关说明,在此不再赘述。支付管理设备与用户终端实施例的不同之处在于,处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序,以用于实现上述第四方面实施例中的支付方法。具体地,存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如,存储器设备),并且当该软件被执行(例如,由一个或多个处理器)时,其可操作来执行参考根据本申请第四方面的实施例中支付方法所描述的操作。
本申请第十一方面提供一种支付系统,该支付系统可包括上述实施例中的用户终端、支付管理设备和后台服务设备。用户终端的具体内容可参见上述实施例中的相关说明,支付管理设备的具体内容可参见上述实施例中的全网支付平台、支付管理装置和支付管理设备的相关说明,后台服务设备的具体内容可参见上述实施例中的宿主程序平台、后台服务装置和后台服务设备的相关内容,在此不再赘述。
本申请第十二方面提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序指令,该计算机程序指令被处理器执行时可实现本申请实施例中的支付方法,且能达到相同的技术效果,为避免重复,这里不再赘述。其中,上述计算机可读存储介质可包括非暂态计算机可读存储介质,如只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等,在此并不限定。
本申请还可提供一种计算机程序产品,该计算机程序产品中的指令由电子设备的处理器执行时,使得电子设备执行本申请实施例中的支付方法,支付方法的具体内容可参见上述实施例中的相关说明,在此不再赘述。电子设备可包括上述实施例中的用户终端、支付管理设备、后台服务设备。
需要明确的是,本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同或相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。对于装置实施例、用户终端实施例、设备实施例、系统实施例和计算机可读存储介质实施例而言,相关之处可以参见方法实施例的说明部分。本申请并不局限于上文所描述并在图中示出的特定步骤和结构。本领域的技术人员可以在领会本申请的精神之后,作出各种改变、修改和添加,或者改变步骤之间的顺序。并且,为了简明起见,这里省略对已知方法技术的详细描述。
上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解,流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器,以产生一种机器,使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解,框图和/或流程图中的每个方框以及框图和/或流程图中的方框的 组合,也可以由执行指定的功能或动作的专用硬件来实现,或可由专用硬件和计算机指令的组合来实现。
本领域技术人员应能理解,上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合,以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上,应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中,术语“包括”并不排除其他装置或步骤;数量词“一个”不排除多个;术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。

Claims (47)

  1. 一种支付方法,应用于支付系统,所述支付系统包括用户终端、全网支付平台和宿主程序平台,所述用户终端具有电子商务应用程序、与所述电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与所述宿主程序集成的第二SDK,所述电子商务应用程序所属第一主体,所述宿主程序所属第二主体,所述第一SDK和所述第二SDK所属第三主体,所述方法包括:
    在所述电子商务应用程序触发支付的情况下,所述用户终端调用所述第一SDK与所述全网支付平台交互,获取第一宿主程序列表,所述第一宿主程序列表包括所述全网支付平台支持的至少部分宿主程序的宿主程序标识;
    在调用所述第一SDK在所述第一宿主程序列表中确定目标宿主程序的情况下,所述用户终端调起所述目标宿主程序;
    所述用户终端通过所述目标宿主程序调用所述第二SDK与所述全网支付平台交互,所述全网支付平台与所述宿主程序平台交互,所述宿主程序平台执行所述目标卡的资源扣除,以完成目标卡的支付,所述目标卡为与所述目标宿主程序绑定的一张资源卡。
  2. 根据权利要求1所述的方法,其中,所述用户终端调用所述第一SDK与所述全网支付平台交互,获取第一宿主程序列表,包括:
    所述用户终端通过电子商务应用程序向所述全网支付平台发送第一支付请求消息,所述第一支付请求消息包括用户标识;
    响应于所述第一支付请求消息,所述全网支付平台根据所述用户标识对应的历史支付数据和/或预存的支付优先级策略,得到所述全网支付平台支持的所述宿主程序的优先级排列顺序;
    所述全网支付平台基于优先级由高到低的前N个所述宿主程序的宿主程序标识,生成所述第一宿主程序列表,N为正整数;
    所述全网支付平台向所述用户终端的所述电子商务应用程序发送所述第一支付反馈消息,所述第一支付反馈消息包括所述第一宿主程序列表。
  3. 根据权利要求1或2所述的方法,在所述用户终端调起所述目标宿主程序之前,还包括:
    所述用户终端调用所述第一SDK从本地获取第二宿主程序列表,所述第二宿主程序列表包括所述用户终端具有的宿主程序的宿主程序标识;
    所述用户终端调用所述第一SDK获取所述第一宿主程序列表和所述第二宿主程序列表的交集,并展示所述交集;所述用户终端响应于用户的第一输入,将所述交集中所述第一输入指示的宿主程序标识对应的宿主程序确定为所述目标宿主程序;
    或者,
    所述用户终端调用所述第一SDK获取所述第一宿主程序列表和所述第二宿主程序列表的交集,将所述交集中宿主程序标识对应的优先级最高的宿主程序确定为所述目标宿主程序。
  4. 根据权利要求1所述的方法,其中,所述用户终端通过所述目标宿主程序调用所述第二SDK与所述全网支付平台交互,所述全网支付平台与所述宿主程序平台交互,所述宿主程序平台执行所述目标卡的资源扣除,以完成目标卡的支付,包括:
    所述用户终端调用所述第二SDK查询所述目标宿主程序是否具有对应的第一标识,所述第一标识用于表征所述宿主程序中的所述用户账号具有利用所述全网支付平台进行支付的功能;
    在所述目标宿主程序具有对应的所述第一标识的情况下,所述用户终端调用所述第二SDK向所述全网支付平台发送第一支付消息,所述第一支付消息包括所述目标宿主程序的宿主程序标识和所述目标宿主程序对应的所述第一标识;
    所述全网支付平台向所述宿主程序平台发送所述第一支付消息;
    所述宿主程序平台根据所述第一支付消息,确定所述目标卡,并执行所述目标卡的资源扣除,完成所述目标卡的支付。
  5. 根据权利要求4所述的方法,其中,所述用户终端通过所述目标宿主程序调用所述第二SDK与所述全网支付平台交互,所述全网支付平台与所述宿主程序平台交互,完成目标卡的支付,还包括:
    在所述目标宿主程序不具有对应的所述第一标识的情况下,所述用户终端调用所述目标宿主程序通过所述宿主程序平台向所述全网支付平台请求所述目标宿主程序对应的所述第一标识;
    所述全网支付平台通过所述宿主程序平台向所述目标宿主程序提供所述第一标识;
    所述用户终端调用所述第二SDK向所述全网支付平台发送第二支付消息,所述第二支付消息包括所述目标宿主程序的宿主程序标识和所述目标宿主程序对应的所述第一标识;
    所述全网支付平台向所述宿主程序平台发送所述第二支付消息;
    所述宿主程序平台根据所述第二支付消息,确定所述目标卡,并执行所述目标卡的资源扣除,完成所述目标卡的支付。
  6. 根据权利要求5所述的方法,其中,所述用户终端调用所述目标宿主程序通过所述宿主程序平台向所述全网支付平台请求所述目标宿主程序对应的所述第一标识,包括:
    在登录所述目标宿主程序的情况下,所述用户终端调用所述目标宿主程序向所述宿主程序平台发送第一标识请求消息,所述第一标识请求消息包括用户身份信息;
    响应于所述第一标识请求消息,所述宿主程序平台向所述全网支付平台发送第二标识请求消息,所述第二标识请求消息包括所述用户身份信息和宿主程序标识;
    所述全网支付平台通过所述宿主程序平台向所述目标宿主程序提供所述第一标识,包括:
    所述全网支付平台根据所述用户身份信息、所述宿主程序标识和预存的已开通用户身份信息,为所述目标宿主程序分配所述第一标识;
    所述全网支付平台向所述宿主程序平台发送第二标识反馈消息,所述第二标识反馈消息包括所述第一标识;
    所述宿主程序平台根据所述第二标识反馈消息,向所述目标宿主程序发送第一标识反馈消息,所述第一标识反馈消息包括所述第一标识。
  7. 根据权利要求6所述的方法,其中,所述用户身份信息包括第一 用户唯一标识和第一电话号码,所述已开通用户身份信息包括第二用户唯一标识和第二电话号码,
    所述全网支付平台根据所述用户身份信息、所述宿主程序标识和预存的已开通用户身份信息,为所述目标宿主程序分配所述第一标识,包括:
    在所述已开通用户身份信息包括目标第二用户唯一标识的情况下,所述全网支付平台绑定第一用户账号和第二用户账号,并生成所述第一标识,所述目标第二用户唯一标识为与所述第一用户唯一标识一致的所述第二用户唯一标识,所述第一用户账号为所述目标宿主程序中与所述第一用户唯一标识对应的用户账号,所述第二用户账号为与所述全网支付平台中所述目标第二用户唯一标识和目标第二电话号码对应的用户账号,所述目标第二电话号码为与所述第一电话号码一致的所述第二电话号码;
    在所述已开通用户身份信息不包括所述目标第二用户唯一标识的情况下,所述全网支付平台新建第三用户账号,绑定所述第一用户账户与所述第三用户账户,并生成所述第一标识,所述第三用户账号为所述全网支付平台中与所述第一用户唯一标识对应的用户账号。
  8. 根据权利要求5所述的方法,在所述用户终端调用所述第二SDK向所述全网支付平台发送第一支付消息之前,或者,在所述用户终端调用所述第二SDK向所述全网支付平台发送第二支付消息之前,还包括:
    所述用户终端调用所述目标宿主程序的所述第二SDK向所述全网支付平台发送版本判定消息;所述全网支付平台根据所述版本判定消息判断所述第二SDK的版本是否为可用版本,并向所述目标宿主程序的所述第二SDK发送版本反馈消息,所述版本反馈消息表征所述第二SDK的版本是否为可用版本;
    和/或,
    所述用户终端调用所述目标宿主程序的第二SDK向所述全网支付平台发送SDK登录判定消息;所述全网支付平台根据所述SDK登录判定消息判断所述第二SDK是否登录,并向所述目标宿主程序的所述第二SDK发送SDK登录反馈消息,所述SDK登录反馈消息表征所述第二SDK是否登录;
    和/或,
    所述用户终端调用所述目标宿主程序的第二SDK向所述全网支付平台发送安全判定消息;所述全网支付平台根据所述安全判定消息判断所述目标宿主程序中的用户账号和本次支付的资源转入账号是否安全,并向所述目标宿主程序的所述第二SDK发送安全反馈消息,所述安全反馈消息表征所述目标宿主程序中的用户账号和所述资源转入账号是否安全。
  9. 根据权利要求6所述的方法,还包括:
    在用户申请资源卡时,所述宿主程序平台向所述全网支付平台发送用户身份信息;
    所述全网支付平台将所述用户身份信息存储为所述已开通用户身份信息。
  10. 根据权利要求1所述的方法,在所述用户终端调用所述第一SDK与所述全网支付平台交互,获取第一宿主程序列表之前,还包括:
    响应于用户的第二输入,所述用户终端通过所述电子商务应用程序向所述全网支付平台发起订单请求;
    响应于所述订单请求,所述全网支付平台为所述电子商务应用程序提供订单信息;
    响应于用户对于订单页面的第三输入,所述用户终端触发支付,所述订单页面包括所述订单信息。
  11. 根据权利要求1所述的方法,还包括:
    所述用户终端调用所述第二SDK向所述全网支付平台发起支付码请求;响应于所述支付码请求,所述全网支付平台向所述第二SDK下发支付码;所述全网支付平台接收所述支付受理终端扫描所述支付码发起的支付请求,与所述宿主程序平台交互,以完成支付请求指示的支付;
    或者,
    所述用户终端调用所述第二SDK扫描收取码,向所述全网支付平台发起支付请求;所述全网支付平台与所述宿主程序平台交互,以完成支付请求指示的支付。
  12. 一种支付方法,应用于用户终端,所述用户终端具有电子商务应 用程序、与所述电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与所述宿主程序集成的第二SDK,所述方法包括:
    在所述电子商务应用程序触发支付的情况下,调用所述第一SDK从全网支付平台获取第一宿主程序列表,所述第一宿主程序列表包括所述全网支付平台支持的至少部分宿主程序的宿主程序标识;
    在调用所述第一SDK在所述第一宿主程序列表中确定目标宿主程序的情况下,调起所述目标宿主程序;
    通过所述目标宿主程序调用所述第二SDK与所述全网支付平台交互,以使所述全网支付平台与宿主程序平台交互,完成目标卡的支付,所述目标卡为与所述目标宿主程序绑定的一张资源卡。
  13. 根据权利要求12所述的方法,其中,所述调用所述第一SDK从所述全网支付平台获取第一宿主程序列表,包括:
    通过所述电子商务应用程序向所述全网支付平台发送第一支付请求消息,所述第一支付请求消息包括用户标识,用于指示所述全网支付平台根据所述用户标识对应的历史支付数据和/或预存的支付优先级策略生成所述第一宿主程序列表,所述第一宿主程序列表包括优先级由高到低排列的N个所述宿主程序的宿主程序标识,N为正整数;
    接收所述全网支付平台发送的第一支付反馈消息,所述第一支付反馈消息包括所述第一宿主程序列表。
  14. 根据权利要求12或13所述的方法,在所述调起所述目标宿主程序之前,还包括:
    调用所述第一SDK从本地获取第二宿主程序列表,所述第二宿主程序列表包括所述用户终端具有的宿主程序的宿主程序标识;
    调用所述第一SDK获取所述第一宿主程序列表和所述第二宿主程序列表的交集,展示所述交集;响应于用户的第一输入,将所述交集中所述第一输入指示的宿主程序标识对应的宿主程序确定为所述目标宿主程序;
    或者,
    调用所述第一SDK获取所述第一宿主程序列表和所述第二宿主程序列表的交集,将所述交集中宿主程序标识对应的优先级最高的宿主程序确 定为所述目标宿主程序。
  15. 根据权利要求12所述的方法,其中,所述调用所述目标宿主程序的第二SDK与所述全网支付平台交互,以使所述全网支付平台与宿主程序平台交互,完成目标卡的支付,包括:
    调用所述第二SDK查询所述目标宿主程序是否具有对应的第一标识,所述第一标识用于表征所述宿主程序中的所述用户账号具有利用所述全网支付平台进行支付的功能;
    在所述目标宿主程序具有对应的所述第一标识的情况下,调用所述第二SDK向所述全网支付平台发送第一支付消息,以使所述全网支付平台向所述宿主程序平台发送所述第一支付消息,由所述宿主程序平台执行所述目标卡的资源扣除,完成所述目标卡的支付,所述第一支付消息包括所述目标宿主程序的宿主程序标识和所述目标宿主程序对应的所述第一标识。
  16. 根据权利要求15所述的方法,其中,所述调用所述目标宿主程序的第二SDK与所述全网支付平台交互,以使所述全网支付平台与宿主程序平台交互,完成目标卡的支付,还包括:
    在所述目标宿主程序不具有对应的所述第一标识的情况下,调用所述目标宿主程序通过所述宿主程序平台向所述全网支付平台请求所述目标宿主程序对应的所述第一标识;
    调用所述目标宿主程序接收所述全网支付平台通过所述宿主程序平台分配的所述目标宿主程序对应的所述第一标识;
    调用所述第二SDK向所述全网支付平台发送第二支付消息,以使所述全网支付平台向所述宿主程序平台发送所述第二支付消息,由所述宿主程序平台执行所述目标卡的资源扣除,完成所述目标卡的支付,所述第二支付消息包括所述目标宿主程序的宿主程序标识和所述目标宿主程序对应的所述第一标识。
  17. 根据权利要求16所述的方法,其中,所述调用所述目标宿主程序通过所述宿主程序平台向所述全网支付平台请求所述目标宿主程序对应的所述第一标识,包括:
    在登录所述目标宿主程序的情况下,调用所述目标宿主程序向所述宿主程序平台发送第一标识请求消息,所述第一标识请求消息包括用户身份信息,用于指示所述宿主程序平台向所述全网支付平台发送第二标识请求消息,所述第二标识请求消息用于请求第一标识,所述第二标识请求消息包括所述用户身份信息和宿主程序标识;
    调用所述目标宿主程序接收所述宿主程序平台发送的第一标识反馈消息,所述第一标识反馈消息包括所述第一标识,所述第一标识反馈信息根据所述全网支付平台向所述宿主程序平台发送的第二标识反馈消息生成,所述第二标识反馈消息包括所述第一标识,所述第一标识由所述全网支付平台根据所述用户身份信息、宿主程序标识以及预存的已开通用户身份信息得到。
  18. 根据权利要求16所述的方法,在所述调用所述第二SDK向所述全网支付平台发送第一支付消息之前,或者,在所述调用所述第二SDK向所述全网支付平台发送第二支付消息之前,还包括:
    调用所述目标宿主程序的所述第二SDK向所述全网支付平台发送版本判定消息,所述版本判定消息指示所述全网支付平台判断所述第二SDK的版本是否为可用版本;通过所述目标宿主程序的所述第二SDK接收所述全网支付平台发送的版本反馈消息,所述版本反馈消息表征所述第二SDK的版本是否为可用版本;
    和/或,
    调用所述目标宿主程序的第二SDK向所述全网支付平台发送SDK登录判定消息,所述SDK登录判定消息指示所述全网支付平台判定所述第二SDK是否登录;通过所述目标宿主程序的第二SDK接收所述全网支付平台发送的SDK登录反馈消息,所述SDK登录反馈消息表征所述第二SDK的版本是否登录;
    和/或,
    调用所述目标宿主程序的第二SDK向所述全网支付平台发送安全判定消息,所述安全判定消息指示所述全网支付平台判断所述目标宿主程序中的用户账号和本次支付的资源转入账号是否安全;通过所述目标宿主程 序的第二SDK接收所述全网支付平台发送的安全反馈消息,所述安全反馈消息表征所述目标宿主程序中的用户账号和所述资源转入账号是否安全。
  19. 根据权利要求17所述的方法,其中,所述已开通用户身份信息包括用户申请资源卡时所述宿主程序平台向所述全网支付平台发送的用户身份信息。
  20. 根据权利要求12所述的方法,在所述调用所述第一SDK从全网支付平台获取第一宿主程序列表之前,还包括:
    响应于用户的第二输入,通过所述电子商务应用程序从所述全网支付平台获取订单信息;
    响应于用户对于订单页面的第三输入,触发支付,所述订单页面包括所述订单信息。
  21. 根据权利要求12所述的方法,还包括:
    调用所述第二SDK从所述全网支付平台获取支付码,所述支付码用于被支付受理终端扫描以向所述全网支付平台发起支付请求;
    或者,
    调用所述第二SDK扫描收取码,向所述全网支付平台发起支付请求。
  22. 一种支付方法,应用于全网支付平台,所述方法包括:
    在用户终端的电子商务应用程序触发支付的情况下,向所述用户终端中与所述电子商务应用程序集成的第一软件开发工具包SDK提供第一宿主程序列表,所述用户终端具有所述电子商务应用程序、第一SDK、宿主程序以及与所述宿主程序集成的第二SDK,所述第一宿主程序列表包括所述全网支付平台支持的至少部分所述宿主程序的宿主程序标识,用于使所述用户终端调用所述第一SDK确定并调起目标宿主程序;
    与所述用户终端通过所述目标宿主程序调用的所述第二SDK、宿主程序平台交互,完成目标卡的支付,所述目标卡为与所述目标宿主程序绑定的一张资源卡。
  23. 根据权利要求22所述的方法,其中,所述向所述用户终端中与 所述电子商务应用程序集成的第一软件开发工具包SDK提供第一宿主程序列表,包括:
    接收所述用户终端通过所述电子商务应用发送的第一支付请求消息,所述第一支付请求消息包括用户标识,
    根据所述用户标识对应的历史支付数据和/或预存的支付优先级策略,得到所述全网支付平台支持的所述宿主程序的优先级排列顺序;
    基于优先级由高到低的前N个所述宿主程序的宿主程序标识,生成所述第一宿主程序列表,N为正整数;
    向所述用户终端的所述电子商务应用程序发送所述第一支付反馈消息,所述第一支付反馈消息包括所述第一宿主程序列表。
  24. 根据权利要求22或23所述的方法,其中,第二宿主程序列表包括所述用户终端具有的宿主程序的宿主程序标识;
    其中,所述目标宿主程序为所述第一宿主程序列表和所述第二宿主程序列表的交集中用户指定的宿主程序标识对应的宿主程序;
    或者,
    所述目标宿主程序为所述第一宿主程序列表和所述第二宿主程序列表的交集中宿主程序标识对应的优先级最高的宿主程序。
  25. 根据权利要求22所述的方法,其中,所述与所述用户终端调用的所述目标宿主程序的所述第二SDK、宿主程序平台交互,完成目标卡的支付,包括:
    在所述用户终端调用所述第二SDK确定所述目标宿主程序具有对应的第一标识的情况下,接收所述用户终端调用所述第二SDK发送的第一支付消息,所述第一标识用于表征所述宿主程序中的所述用户账号具有利用所述全网支付平台进行支付的功能;
    向所述宿主程序平台发送所述第一支付消息,所述第一支付消息指示所述宿主程序平台执行所述目标卡的资源扣除,完成所述目标卡的支付,所述第一支付消息包括所述目标宿主程序的宿主程序标识和所述目标宿主程序对应的所述第一标识。
  26. 根据权利要求25所述的方法,其中,所述与所述用户终端调用 的所述目标宿主程序的所述第二SDK、宿主程序平台交互,完成目标卡的支付,还包括:
    在所述用户终端调用所述第二SDK确定所述目标宿主程序不具有对应的所述第一标识的情况下,通过所述宿主程序平台向所述目标宿主程序提供所述第一标识;
    接收所述用户终端调用所述第二SDK发送的第二支付消息;
    向所述宿主程序平台发送所述第二支付消息,所述第二支付消息指示所述宿主程序平台执行所述目标卡的资源扣除,完成所述目标卡的支付,所述第二支付消息包括所述目标宿主程序的宿主程序标识和所述目标宿主程序对应的所述第一标识。
  27. 根据权利要求26所述的方法,其中,所述通过所述宿主程序平台向所述目标宿主程序提供所述第一标识,包括:
    在登录所述目标宿主程序的情况下,接收所述宿主程序平台发送的第二标识请求消息,所述第二标识请求消息包括用户身份信息和宿主程序标识,所述第二标识请求消息根据所述终端设备调用所述目标宿主程序发送的第一标识请求消息生成,所述第一标识请求消息包括所述用户身份信息;
    根据所述用户身份信息、所述宿主程序标识和预存的已开通用户身份信息,为所述目标宿主程序分配所述第一标识;
    向所述宿主程序平台发送第二标识反馈消息,以使所述宿主程序平台根据所述第二标识反馈消息向所述目标宿主程序发送第一标识反馈消息,所述第一标识反馈消息和所述第二标识反馈消息包括所述第一标识。
  28. 根据权利要求27所述的方法,其中,所述用户身份信息包括第一用户唯一标识和第一电话号码,所述已开通用户身份信息包括第二用户唯一标识和第二电话号码,
    所述根据所述用户身份信息、所述宿主程序标识和预存的已开通用户身份信息,为所述目标宿主程序分配所述第一标识,包括:
    在所述已开通用户身份信息包括目标第二用户唯一标识的情况下,绑定第一用户账号和第二用户账号,并生成所述第一标识,所述目标第二用 户唯一标识为与所述第一用户唯一标识一致的所述第二用户唯一标识,所述第一用户账号为所述目标宿主程序中与所述第一用户唯一标识对应的用户账号,所述第二用户账号为与所述全网支付平台中所述目标第二用户唯一标识和目标第二电话号码对应的用户账号,所述目标第二电话号码为与所述第一电话号码一致的所述第二电话号码;
    在所述已开通用户身份信息不包括所述目标第二用户唯一标识的情况下,新建第三用户账号,绑定所述第一用户账户与所述第三用户账户,并生成所述第一标识,所述第三用户账号为所述全网支付平台中与所述第一用户唯一标识对应的用户账号。
  29. 根据权利要求26所述的方法,在所述向所述宿主程序平台发送所述第一支付消息之前,或者,在所述向所述宿主程序平台发送所述第二支付消息之前,还包括:
    接收所述用户终端调用所述目标宿主程序的所述第二SDK发送的版本判定消息;根据所述版本判定消息判断所述第二SDK的版本是否为可用版本;向所述目标宿主程序的所述第二SDK发送版本反馈消息,所述版本反馈消息表征所述第二SDK的版本是否为可用版本;
    和/或,
    接收所述用户终端调用所述目标宿主程序的所述第二SDK发送的SDK登录判定消息;根据所述SDK登录判定消息判断所述第二SDK是否登录;向所述目标宿主程序的所述第二SDK发送SDK登录反馈消息,所述SDK登录反馈消息表征所述第二SDK是否登录;
    和/或,
    接收所述用户终端调用所述目标宿主程序的所述第二SDK发送的安全判定消息;根据所述安全判定消息判断所述目标宿主程序中的用户账号和本次支付的资源转入账号是否安全;向所述目标宿主程序的所述第二SDK发送安全反馈消息,所述安全反馈消息表征所述目标宿主程序中的用户账号和所述资源转入账号是否安全。
  30. 根据权利要求27所述的方法,还包括:
    在用户申请资源卡时,接收所述宿主程序平台发送的用户身份信息;
    将所述用户身份信息存储为所述已开通用户身份信息。
  31. 根据权利要求22所述的方法,在所述向所述用户终端中与所述电子商务应用程序集成的第一软件开发工具包SDK提供第一宿主程序列表之前,还包括:
    响应于所述电子商务应用程序的订单请求,为所述电子商务应用程序提供订单信息。
  32. 根据权利要求22所述的方法,还包括:
    响应于所述用户终端调用所述第二SDK的支付码请求,向所述第二SDK下发支付码;接收所述支付受理终端扫描所述支付码发起的支付请求,与所述宿主程序平台交互,以完成支付请求指示的支付;
    或者,
    接收所述用户终端调用所述第二SDK扫描收取码发起的支付请求;与所述宿主程序平台交互,以完成支付请求指示的支付。
  33. 一种支付方法,应用于宿主程序平台,所述方法包括:
    在用户终端的电子商务应用程序触发支付的情况下,与所述全网支付平台交互,确定用于支付的目标卡,所述用户终端具有所述电子商务应用程序、与所述电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与所述宿主程序集成的第二SDK,所述目标卡为与目标宿主程序绑定的一张资源卡,所述目标卡根据所述用户终端调用的所述目标宿主程序的第二SDK与所述全网支付平台交互确定,所述目标宿主程序为所述用户终端调用所述第一SDK在所述第一宿主程序列表中确定的所述宿主程序,所述第一宿主程序列表包括所述全网支付平台支持的至少部分所述宿主程序的宿主程序标识;
    执行所述目标卡的资源扣除,以完成所述目标卡的支付。
  34. 根据权利要求33所述的方法,其中,所述第一宿主程序列表包括优先级由高到低排列的N个所述宿主程序的宿主程序标识,N为整数,优先级根据所述用户终端通过电子商务应用提供的用户标识对应的历史支付数据和/或预存的支付优先级策略确定。
  35. 根据权利要求33或34所述的方法,其中,第二宿主程序列表包 括所述用户终端具有的宿主程序的宿主程序标识;
    其中,所述目标宿主程序为所述第一宿主程序列表和所述第二宿主程序列表的交集中用户指定的宿主程序标识对应的宿主程序;
    或者,
    所述目标宿主程序为所述第一宿主程序列表和所述第二宿主程序列表的交集中宿主程序标识对应的优先级最高的宿主程序。
  36. 根据权利要求33所述的方法,其中,所述在用户终端的电子商务应用程序触发支付的情况下,与所述全网支付平台交互,确定用于支付的目标卡,包括:
    在所述用户终端调用所述第二SDK确定所述目标宿主程序具有对应的第一标识的情况下,接收所述用户终端调用所述第二SDK通过所述全网支付平台方发送的第一支付消息,所述第一支付消息包括所述目标宿主程序的宿主程序标识和所述目标宿主程序对应的所述第一标识;
    根据所述第一支付消息,确定所述目标卡。
  37. 根据权利要求36所述的方法,其中,所述在用户终端的电子商务应用程序触发支付的情况下,与所述全网支付平台交互,确定用于支付的目标卡,还包括:
    在所述用户终端调用所述第二SDK确定所述目标宿主程序不具有对应的第一标识的情况下,接收所述用户终端调用所述第二SDK通过所述全网支付平台方发送的第二支付消息,所述第二支付消息包括所述目标宿主程序的宿主程序标识和所述全网支付平台分配的所述目标宿主程序对应的所述第一标识;
    根据所述第二支付消息,确定所述目标卡。
  38. 根据权利要求37所述的方法,在所述与所述全网支付平台交互,确定用于支付的目标卡之前,还包括:
    在登录所述目标宿主程序的情况下,接收所述用户终端调用所述目标宿主程序发送的第一标识请求消息,所述第一标识请求消息包括用户身份信息;
    响应于所述第一标识请求消息,向所述全网支付平台发送第二标识请 求消息,所述第二标识请求消息用于请求第一标识,所述第二标识请求消息包括所述用户身份信息和宿主程序标识;
    接收所述全网支付平台发送的第二标识反馈消息,所述第二标识反馈消息包括所述第一标识,所述第一标识由所述全网支付平台根据所述用户身份信息、宿主程序标识以及预存的已开通用户身份信息得到;
    根据所述第二标识反馈消息,向所述用户终端的所述目标宿主程序发送第一标识反馈消息,所述第一标识反馈消息包括所述第一标识。
  39. 根据权利要求38所述的方法,还包括:
    在用户申请资源卡时,向所述全网支付平台发送用户身份信息,以使所述全网支付平台将所述用户身份信息存储为所述已开通用户身份信息。
  40. 一种用户终端,所述用户终端具有电子商务应用程序、与所述电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与所述宿主程序集成的第二SDK,所述用户终端包括调用模块和交互模块;
    所述调用模块用于在所述电子商务应用程序触发支付的情况下,调用所述第一SDK利用所述交互模块从全网支付平台获取第一宿主程序列表,所述第一宿主程序列表包括所述全网支付平台支持的至少部分宿主程序的宿主程序标识;以及,还用于在调用所述第一SDK在所述第一宿主程序列表中确定目标宿主程序的情况下,调起所述目标宿主程序;
    所述调用模块用于通过所述目标宿主程序调用所述第二SDK利用所述交互模块与所述全网支付平台交互,以使所述全网支付平台与宿主程序平台交互,完成目标卡的支付,所述目标卡为与所述目标宿主程序绑定的一张资源卡。
  41. 一种支付管理装置,包括交互模块,所述交互模块包括发送单元;
    所述发送单元,用于在用户终端的电子商务应用程序触发支付的情况下,向所述用户终端中与所述电子商务应用程序集成的第一软件开发工具包SDK提供第一宿主程序列表,所述用户终端具有所述电子商务应用程序、第一SDK、宿主程序以及与所述宿主程序集成的第二SDK,所述第一宿主程序列表包括所述全网支付平台支持的至少部分所述宿主程序的宿 主程序标识,用于使所述用户终端调用所述第一SDK确定并调起目标宿主程序;
    所述交互模块,用于与所述用户终端通过所述目标宿主程序调用的所述第二SDK、宿主程序平台交互,完成目标卡的支付,所述目标卡为与所述目标宿主程序绑定的一张资源卡。
  42. 一种后台服务装置,包括:
    交互模块,用于在用户终端的电子商务应用程序触发支付的情况下,与所述全网支付平台交互,确定用于支付的目标卡,所述用户终端具有所述电子商务应用程序、与所述电子商务应用程序集成的第一软件开发工具包SDK、宿主程序以及与所述宿主程序集成的第二SDK,所述目标卡为与目标宿主程序绑定的一张资源卡,所述目标卡根据所述用户终端调用的所述目标宿主程序的第二SDK与所述全网支付平台交互确定,所述目标宿主程序为所述用户终端调用所述第一SDK在所述第一宿主程序列表中确定的所述宿主程序,所述第一宿主程序列表包括所述全网支付平台支持的至少部分所述宿主程序的宿主程序标识;
    执行模块,用于执行所述目标卡的资源扣除,以完成所述目标卡的支付。
  43. 一种用户终端,包括:处理器以及存储有计算机程序指令的存储器;
    所述处理器执行所述计算机程序指令时实现如权利要求12至21中任意一项所述的支付方法。
  44. 一种支付管理设备,包括:处理器以及存储有计算机程序指令的存储器;
    所述处理器执行所述计算机程序指令时实现如权利要求22至32任意一项所述的支付方法。
  45. 一种后台服务设备,包括:处理器以及存储有计算机程序指令的存储器;
    所述处理器执行所述计算机程序指令时实现如权利要求33至39任意一项所述的支付方法。
  46. 一种支付系统,包括如权利要求43所述的用户终端、如权利要求44所述的支付管理设备和如权利要求45所述的后台服务设备。
  47. 一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序指令,所述计算机程序指令被处理器执行时实现如权利要求1至39中任意一项所述的支付方法。
PCT/CN2022/115584 2022-03-24 2022-08-29 支付方法、用户终端、装置、设备、系统及介质 WO2023178924A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210294467.6A CN114707976A (zh) 2022-03-24 2022-03-24 支付方法、用户终端、装置、设备、系统及介质
CN202210294467.6 2022-03-24

Publications (1)

Publication Number Publication Date
WO2023178924A1 true WO2023178924A1 (zh) 2023-09-28

Family

ID=82170776

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/115584 WO2023178924A1 (zh) 2022-03-24 2022-08-29 支付方法、用户终端、装置、设备、系统及介质

Country Status (3)

Country Link
CN (1) CN114707976A (zh)
TW (1) TWI839875B (zh)
WO (1) WO2023178924A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114707976A (zh) * 2022-03-24 2022-07-05 中国银联股份有限公司 支付方法、用户终端、装置、设备、系统及介质
CN115293753A (zh) * 2022-07-19 2022-11-04 中国银联股份有限公司 基于智能路由的远程支付方法、终端、装置、系统及介质

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109960447A (zh) * 2017-12-25 2019-07-02 新智数字科技有限公司 支付方法和支付装置
WO2021088671A1 (zh) * 2019-11-06 2021-05-14 上海连尚网络科技有限公司 一种端能力的调用方法、设备和计算机存储介质
CN112860457A (zh) * 2021-02-22 2021-05-28 招联消费金融有限公司 软件开发工具包调用方法、装置、计算机设备和存储介质
CN112966196A (zh) * 2021-03-26 2021-06-15 深圳九星互动科技有限公司 一种网页聚合支付的跳转控制方法、装置、系统及介质
WO2021143371A1 (zh) * 2020-01-16 2021-07-22 支付宝(杭州)信息技术有限公司 一种小程序页面的生成方法、装置及设备
CN113222570A (zh) * 2021-04-21 2021-08-06 中国银联股份有限公司 支付方法、平台设备、系统及存储介质
CN113656087A (zh) * 2020-04-29 2021-11-16 腾讯科技(深圳)有限公司 小程序启动方法、装置、设备及存储介质
CN114116036A (zh) * 2020-08-11 2022-03-01 腾讯科技(深圳)有限公司 应用程序插件的调用方法、装置、介质及电子设备
CN114707976A (zh) * 2022-03-24 2022-07-05 中国银联股份有限公司 支付方法、用户终端、装置、设备、系统及介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW201106286A (en) * 2009-08-05 2011-02-16 Alibaba Group Holding Ltd System and method for adaptively selecting bank card for payment
CN105930040A (zh) * 2015-02-27 2016-09-07 三星电子株式会社 包含电子支付系统的电子装置及其操作方法
CN107341650A (zh) * 2016-01-19 2017-11-10 广州爱九游信息技术有限公司 虚拟资源的转移方法及装置

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109960447A (zh) * 2017-12-25 2019-07-02 新智数字科技有限公司 支付方法和支付装置
WO2021088671A1 (zh) * 2019-11-06 2021-05-14 上海连尚网络科技有限公司 一种端能力的调用方法、设备和计算机存储介质
WO2021143371A1 (zh) * 2020-01-16 2021-07-22 支付宝(杭州)信息技术有限公司 一种小程序页面的生成方法、装置及设备
CN113656087A (zh) * 2020-04-29 2021-11-16 腾讯科技(深圳)有限公司 小程序启动方法、装置、设备及存储介质
CN114116036A (zh) * 2020-08-11 2022-03-01 腾讯科技(深圳)有限公司 应用程序插件的调用方法、装置、介质及电子设备
CN112860457A (zh) * 2021-02-22 2021-05-28 招联消费金融有限公司 软件开发工具包调用方法、装置、计算机设备和存储介质
CN112966196A (zh) * 2021-03-26 2021-06-15 深圳九星互动科技有限公司 一种网页聚合支付的跳转控制方法、装置、系统及介质
CN113222570A (zh) * 2021-04-21 2021-08-06 中国银联股份有限公司 支付方法、平台设备、系统及存储介质
CN114707976A (zh) * 2022-03-24 2022-07-05 中国银联股份有限公司 支付方法、用户终端、装置、设备、系统及介质

Also Published As

Publication number Publication date
TWI839875B (zh) 2024-04-21
TW202338687A (zh) 2023-10-01
CN114707976A (zh) 2022-07-05

Similar Documents

Publication Publication Date Title
US9864987B2 (en) Account provisioning authentication
CN109691014B (zh) 物联网装置和应用程序之间的生物计量识别和验证
US10433128B2 (en) Methods and systems for provisioning multiple devices
WO2023178924A1 (zh) 支付方法、用户终端、装置、设备、系统及介质
KR102141836B1 (ko) 이중 인증
CN109064146B (zh) 一种数字货币交易方法、设备、系统、终端及客户端钱包
CN106934622B (zh) 一种共享账户的方法和装置
US20150142673A1 (en) Methods and systems for token request management
JP6615297B2 (ja) ネットワークトランザクションとの関連でユーザを認証するために用いるシステム及び方法
CN107026815A (zh) 一种支付业务处理方法、支付服务器、相关设备及系统
CN113179282A (zh) 合并账号的方法、装置和服务器
WO2022222581A1 (zh) 支付方法、平台设备、系统及存储介质
CN108848061B (zh) 一种用户信息传输方法及终端设备
CN109426961B (zh) 一种绑卡风险控制方法及装置
WO2024016634A1 (zh) 基于智能路由的远程支付方法、终端、装置、系统及介质
US12099987B2 (en) Hybrid tokenization for push payments
TW201606678A (zh) 用以提供信貸之系統及方法
CN117172786A (zh) 身份认证方法、装置、设备、介质和程序产品
KR101505847B1 (ko) 결제 처리를 위한 제휴사 앱 인증 방법
CN111930535B (zh) 一种应用功能调用方法、装置、计算机设备及存储介质
WO2019025868A1 (en) SYSTEM AND METHOD FOR PROVIDING SECURE SERVICES
CN115310958A (zh) 基于5g消息应用的支付方法、装置、设备、系统及介质
US20140006271A1 (en) Cross-network electronic payment processing system and method
US20190156334A1 (en) System and method for providing anonymous payments
TW202405727A (zh) 網路支付業務開通方法、裝置、設備、系統及介質

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: 22932976

Country of ref document: EP

Kind code of ref document: A1