WO2023168938A1 - 支付方法、终端设备、服务器、系统及介质 - Google Patents
支付方法、终端设备、服务器、系统及介质 Download PDFInfo
- Publication number
- WO2023168938A1 WO2023168938A1 PCT/CN2022/123922 CN2022123922W WO2023168938A1 WO 2023168938 A1 WO2023168938 A1 WO 2023168938A1 CN 2022123922 W CN2022123922 W CN 2022123922W WO 2023168938 A1 WO2023168938 A1 WO 2023168938A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- sdk
- payment
- user verification
- server
- verification
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
Definitions
- This application belongs to the field of data processing, and in particular relates to a payment method, terminal equipment, server, system and medium.
- SDK Software Development Kit
- the payment process involves two entities, the application and the SDK, in the terminal device.
- the application and the SDK
- the security risks of payment also increase. Therefore, there is an urgent need for a payment method that can improve security.
- the embodiments of this application provide a payment method, terminal device, server, system and medium, which can improve the security of payment.
- embodiments of the present application provide a payment method applied to a software development tool kit SDK server.
- the method includes: in response to the received payment request message, sending a security verification request message to the security control system, where the security verification request message includes a security Verification information is used to instruct the security control system to perform security verification on the payment corresponding to the payment request message based on the security verification information; to receive the security verification result information sent by the security control system; when the security verification result information indicates that the security verification has passed, send a message to the terminal
- the SDK in the device sends a first notification message.
- the terminal device has the SDK and the host program.
- the first notification message is used to instruct the SDK to notify the host program to display the user verification page to prompt the user to enter the first user verification input information.
- the first user verification input The information is used by the host program server to perform user verification to obtain user verification result information; when the user verification result information indicates that the user has passed the verification, a payment request is initiated to complete the payment.
- embodiments of the present application provide a payment method, which is applied to a terminal device.
- the terminal device has a software development tool kit SDK and a host program.
- the method includes: obtaining the first notification message sent by the SDK server through the SDK, and the first notification message It is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is obtained by the security control system performing security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- Security verification request The message is sent by the SDK server in response to the received payment request message; in response to the first notification message, the host program is notified through the SDK to display the user verification page to prompt the user to enter the first user verification input information; the host program feeds back the second user verification input information to the host program server through the host program
- One user verification input information the first user verification input information is used by the host program server to perform user verification to obtain user verification result information; the user verification result information obtained from the host program server through the host program is sent to the SDK server through the SDK, so that the SDK server When the user verification result information indicates that the user verification has passed, a payment request is initiated to complete the payment.
- embodiments of the present application provide a payment method applied to a host program server.
- the method includes: receiving the first user verification input information fed back by the terminal device through the host program, and the terminal device has a software development tool kit SDK and the host program,
- the first user verification input information is obtained after the SDK notifies the host program to display the user verification page in response to the first notification message.
- the first notification message is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is safe.
- the control system performs security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- the security verification request message is sent by the SDK server in response to the received payment request message; user verification is performed based on the first user verification input information. , obtain the user verification result information; send the user verification result information to the host program in the terminal device, and transmit the user verification result information to the SDK through the host program, so that the SDK sends the user verification result information to the SDK server, and the user verification result information is represented If the user passes the verification, the SDK server initiates a payment request to complete the payment.
- an SDK server including: a sending module, configured to send a security verification request message to the security control system in response to the received payment request message, where the security verification request message includes security verification information, for Instruct the security control system to perform security verification on the payment corresponding to the payment request message based on the security verification information; the receiving module is used to receive the security verification result information sent by the security control system; the sending module is also used to indicate that the security verification result information has passed the security verification.
- a first notification message is sent to the SDK in the terminal device, and the terminal device has the SDK and the host program.
- the first notification message is used to instruct the SDK to notify the host program to display the user verification page to prompt the user to enter the first user verification input information
- the first user verification input information is used by the host program server to perform user verification to obtain user verification result information; the sending module is also used to initiate a payment request to complete the payment when the user verification result information indicates that the user verification has passed.
- inventions of the present application provide a terminal device.
- the terminal device has a software development tool kit SDK and a host program.
- the terminal device includes: a receiving module for obtaining the first notification message sent by the SDK server through the SDK.
- the first notification is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is obtained by the security control system performing security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- the request message is sent by the SDK server in response to the received payment request message; the display module is used to respond to the first notification message, notify the host program through the SDK to display the user verification page to prompt the user to enter the first user verification input information; the sending module, The first user verification input information is used to feed back the first user verification input information to the host program server through the host program.
- the first user verification input information is used for user verification by the host program server to obtain user verification result information; the sending module is also used to send the pass to the SDK server through the SDK.
- the user verification result information obtained by the host program from the host program server enables the SDK server to initiate a payment request to complete the payment when the user verification result information indicates that the user has passed the verification.
- embodiments of the present application provide a host program server, including: a receiving module configured to receive the first user verification input information fed back by the terminal device through the host program; the terminal device has a software development toolkit SDK and the host program; A user verification input information is obtained after the SDK notifies the host program to display the user verification page in response to the first notification message.
- the first notification message is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is a security control
- the system performs security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- the security verification request message is sent by the SDK server in response to the received payment request message; the verification module is used to verify the input according to the first user
- the information is used for user verification to obtain user verification result information;
- the sending module is used to send user verification result information to the host program in the terminal device, and transmits the user verification result information to the SDK through the host program, so that the SDK sends user verification to the SDK server.
- the result information when the user verification result information indicates that the user verification has passed, causes the SDK server to initiate a payment request to complete the payment.
- embodiments of the present application provide an SDK server, including: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the payment method of the first aspect is implemented.
- embodiments of the present application provide a terminal device, 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 host program server, 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 payment system, including the SDK server of the seventh aspect, the terminal device of the eighth aspect, and the host program server of the ninth aspect.
- embodiments of the present application provide a computer-readable storage medium.
- Computer program instructions are stored on the computer-readable storage medium.
- the payment method of the first aspect and the payment method of the second aspect are implemented.
- Payment method or payment method of a third party are implemented.
- the application embodiment provides a payment method, terminal device, server, system and medium.
- the SDK server sends a security verification request message to the security control system to request the security control system to perform security verification on this payment. Complete the security verification required by the SDK owner.
- the SDK server sends a message to the SDK of the terminal device to instruct the SDK to notify the host program to display the user verification page, so that the SDK can trigger the host program to actively initiate user verification to complete the requirements of the host program owner. Verification of user identity security.
- two-way verification is realized between the SDK owner and the host program owner, which improves the security of payment.
- Figure 1 is a schematic diagram of an example of an application scenario of the payment method 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 yet another embodiment of the payment method provided in the first aspect of this application.
- FIG. 6 is a flow chart of yet another embodiment of the payment method provided in the first aspect of this application.
- FIG. 7 is a flow chart of an embodiment of the payment method provided in the second aspect of this application.
- FIG. 8 is a flow chart of another embodiment of the payment method provided in the second aspect of this application.
- FIG. 9 is a flow chart of yet another embodiment of the payment method provided in the second aspect of this application.
- Figure 10 is a flow chart of yet another embodiment of the payment method provided in the second aspect of this application.
- FIG 11 is a flow chart of yet another embodiment of the payment method provided in the second aspect of this application.
- Figure 12 is a flow chart of an embodiment of the payment method provided in the third aspect of this application.
- Figure 13 is a flow chart of another embodiment of the payment method provided in the third aspect of this application.
- Figure 14 is a flow chart of an example of the payment process provided by the embodiment of the present application.
- Figure 15 is a flow chart of another example of the payment process provided by the embodiment of the present application.
- Figure 16 is a flow chart of another example of the payment process provided by the embodiment of the present application.
- Figure 17 is a schematic structural diagram of an embodiment of the SDK server provided in the fourth aspect of this application.
- Figure 18 is a schematic structural diagram of an embodiment of the terminal device provided in the fifth aspect.
- Figure 19 is a schematic structural diagram of an embodiment of the host program server provided in the sixth aspect.
- Figure 20 is a schematic structural diagram of an embodiment of the SDK server provided in the seventh aspect of this application.
- the application of electronic payment is becoming more and more widespread. Users can pay through terminal devices.
- the terminal device can also be equipped with an SDK.
- the SDK can be integrated into the application and realize payment together with the application.
- the payment process will involve two entities, the application and the SDK, in the terminal device.
- the security risks of payment will also increase. Therefore, there is an urgent need for a payment method that can improve security.
- Embodiments of the present application provide a payment method, terminal device, server, system and medium that can perform double verification with SDK and host program as the main body respectively.
- SDK as the main body verification
- the host program as the main body verification both pass Click to complete the payment.
- the security of SDK-related interactions and host program-related interactions is ensured through verification of both the SDK and the host program, thereby improving the security of the entire payment process.
- FIG. 1 is a schematic diagram of an example of an application scenario of the payment method provided by the embodiment of the present application.
- the terminal device 11 can communicate and interact with the SDK background system 12 and the host program background system 13 respectively.
- the SDK background system 12 can also communicate and interact with the host program background system 13 and the security control system 14 respectively.
- the terminal device 11 has a host program and SDK.
- the payment function of the terminal device 11 requires the host program to call the SDK to implement it.
- the SDK in the terminal device 11 can interact with the host program.
- the SDK in the terminal device 11 can communicate and interact with the SDK backend system 12
- the host program in the terminal device 11 can communicate and interact with the host program backend system 13 .
- the terminal device 11 is a device used by the user to make payment, and may specifically include a mobile phone, a tablet computer, a computer, a wearable device, etc., and is not limited here.
- the SDK backend system 12 is the backend system of the SDK and may include more than one SDK server.
- the type and number of SDK servers in the SDK backend system 12 are not limited here.
- the terminal device 11 will send payment-related information to the SDK backend system 12 through the SDK.
- the SDK backend system 12 may also pre-store the account information and personal information of the paying user.
- the SDK background system 12 may include an SDK background subsystem and a payment code subsystem.
- the SDK background subsystem and the payment code subsystem may communicate and interact with each other.
- the SDK background subsystem may also communicate and interact with the SDK in the terminal device 11 , the payment code subsystem can communicate and interact with the host program backend system.
- the payment code subsystem stores payment code related information and can manage and verify payment codes.
- the payment code may include a collection code, a payment code, etc.
- the payment code may specifically be a QR code or other form of graphic code, which is not limited here.
- the host program backend system 13 is a backend system for the host program and may include more than one host program server.
- the type and number of host program servers in the host program backend system 13 are not limited here.
- the terminal device 11 will interact with the host program backend system 13 through the host program.
- the host program backend system 13 can also communicate and interact with the SDK backend system 12.
- the security control system 14 can be used to securely verify payment, and can include more than one electronic device. The type and quantity of the electronic devices in the security control system 14 are not limited here.
- the security control system 14 can communicate and interact with the SDK backend system 12. In the case where the SDK background system 12 includes an SDK background subsystem and a payment code subsystem, the security control system 14 can communicate and interact with the SDK background subsystem therein.
- the information transmission between the SDK and the host program in the terminal device 11 is encrypted transmission, that is, the information exchanged between the SDK and the host program in the terminal device 11 is encrypted information.
- the encryption and decryption algorithms required for encryption and decryption are stored in the SDK and the host program respectively.
- the encryption and decryption algorithms in the SDK and the host program can be set according to the application environment and requirements.
- the encryption and decryption algorithms in the SDK and the host program Algorithms may include SM2 algorithm, SM4 algorithm, Data Encryption Standard (DES), RSA algorithm, etc., which are not limited here.
- the keys required for encryption and decryption algorithms in the SDK can be stored and managed by the SDK backend system 12 , that is, the keys for encryption and decryption in the SDK can be stored in the SDK server in the SDK backend system 12 , and the SDK can communicate with the SDK backend system 12 Interact to achieve encryption and decryption.
- the keys required for encryption and decryption algorithms in the host program can be stored and managed by the host program backend system 13, that is, the keys for encryption and decryption in the host program are stored in the host program server in the host program backend system 13.
- the host program can communicate with The host program background system 13 interacts to implement encryption and decryption. Through the ciphertext transmission between the SDK and the host program, the information transmitted between the SDK and the host program is not easily stolen, ensuring the security of the communication between the SDK and the host program.
- the SDK in the terminal device 11 may have a security domain, and information in the SDK may be stored in the security domain.
- the security domain can be an encrypted data storage space, which can be implemented through hardware and/or software, such as through Secure Element (SE) and/or Trusted Execution Environment (TrustedExecutionEnvironment, TEE).
- SE Secure Element
- TEE Trusted Execution Environment
- the SDK can manage the permissions of the security domain, such as dividing data that cannot be openly read and data that only the host program has permission to read.
- the first aspect of this application provides a payment method, which is applied to the SDK server, that is, the payment method can be executed by the SDK server.
- 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 S204.
- step S201 in response to the received payment request message, a security verification request message is sent to the security control system.
- the payment request message is used to initiate payment.
- the payment request message may be sent by the SDK in the terminal device to the SDK server, or the payment request message may be sent by the payment acceptance device to the SDK server.
- the SDK background system includes the SDK background subsystem and the payment code subsystem
- the payment acceptance device can initiate payment to the SDK server in the payment code subsystem, and the SDK server in the payment code subsystem then sends the payment code to the SDK server in the SDK background subsystem.
- the payment request message may include order information, terminal device information, payment information, etc. Order information may include order identification, order initiator, order details, order amount, order time and other information associated with the order, which is not limited here.
- the terminal device information may include information related to the terminal device such as the geographical location and device identification of the terminal device making this payment, which is not limited here.
- Payment information may include payment payer information, payment payee information, payment amount, payment time and other payment-related information, which is not limited here.
- the payment payee information may include merchant name, merchant account and other information, and the payment payee information may include payer account, payer payment card information, payer identification and other information, which is not limited here.
- the security verification request message includes security verification information.
- the security verification request message is used to instruct the security control system to perform security verification on the payment corresponding to the payment request message based on the security verification information.
- the security verification information may include at least part of the information sent by the SDK in the terminal device to the SDK server.
- the security verification information may also include the payment party information pre-stored in the SDK server and indicated by the payment request message, etc., which is not limited here.
- the security verification information may include the payment card number, the payer's login account, the mobile phone number associated with the payer's login account, the mobile phone number associated with the payment card, terminal device identification, geographical location of the terminal device, payment amount, payment time, payment card One or more of the historical payment information and other information.
- the security verification information may also include other information that can be used for security verification, which is not limited here.
- the payment card number can be the default payment card number provided by the SDK in the terminal device. If the user switches the default payment card on the terminal device, the default payment card number will occur. In the event of a change, the SDK will send a message including the new default payment card number to the SDK server, and the SDK server will be triggered to send a security verification request message including the new default payment card number to the security control system again. That is to say, if the user switches the default payment card on the payment details page displayed on the terminal device, the SDK server will re-send a security verification request message including the switched default payment card number to the security control system.
- the security control system receives the security verification request message and performs security verification based on the security verification information in the security verification request message.
- Security verification can verify the legality of payment and the security of the login status of the payment terminal device. Specifically, it can be determined whether the security verification is passed by whether the security verification information meets the predetermined security judgment conditions. Safety determination conditions can be set according to specific scenarios, needs, etc., and are not limited here.
- the security verification information includes the terminal device identifier of this payment and the historical payment information of the payment card.
- the historical payment information of the payment card includes the terminal device identifier of the payment card in historical payments. If the terminal device identifier of this payment and the payment card If the terminal device identifiers in the historical payments are consistent, the security verification passes; otherwise, the security verification fails.
- the security verification information includes the geographical location of the terminal device used for this payment, the payment time, and the historical payment information of the payment card.
- the historical payment information of the payment card includes the geographical location and payment time of the terminal device used for the most recent payment by the payment card. If The time between the payment time of the payment card's most recent payment and the payment time of this payment is less than the preset time, and the geographical location of the terminal device for the payment card's most recent payment and the location of the terminal device for this payment are less than the preset time. If the distance is greater than the preset distance, the security verification fails; otherwise, the security verification passes.
- the security verification information includes the mobile phone number associated with the payer's login account and the mobile phone number associated with the payment card. If the mobile phone number associated with the payer's login account is consistent with the mobile phone number associated with the payment card, the security verification is passed; otherwise, it is safe. Verification failed.
- the security verification is determined to have failed when the security risk is very high, such as insufficient account balance, illegal payment, etc.
- the security verification can be judged to have passed.
- the security verification information includes the terminal device identification of this payment and the historical payment information of the payment card.
- the historical payment information of the payment card includes the terminal device identification of the payment card in historical payments. Since the user may change the terminal device, if If the terminal device identifier of this payment is inconsistent with the terminal device identifier of the payment card's historical payments, it can also be regarded as passing the security verification.
- user verification can be used to determine whether the user himself is using the replaced terminal device to make the payment.
- the security verification information includes the payment amount of this payment and the payer's account balance. If the payment amount of this payment is less than or equal to the payer's account balance, the security verification is passed; otherwise, the security verification is not passed.
- the SDK when the SDK receives a payment request message and detects that the currently logged-in user account is not associated with a payment card, it can send a card binding prompt message to prompt the user to enter the card binding process to bind the payment card. After binding the payment card, the SDK then sends a security verification request message to the security control system.
- step S202 the security verification result information sent by the security control system is received.
- the security control system performs security verification based on the security verification information and can obtain security verification result information for this payment, that is, the payment indicated by the payment request message.
- the security verification result information is used to indicate whether the security verification is passed. If the security verification result information indicates that the security verification has not passed, the SDK server can send an instruction message to the SDK in the terminal device, so that the SDK issues a pop-up message to suspend payment.
- the SDK in the terminal device can call the preset query interface to retrieve the payment information such as payer information, order number, etc.
- the order information is transmitted to the SDK server.
- the SDK server can further supplement other order information for this payment, such as the merchant number and other payment information related to the payment, and synchronize the payment information and order information to the host program server to implement the SDK server. Synchronization of information about this payment with the host program server.
- the SDK background subsystem includes the SDK background subsystem and the payment code subsystem
- the SDK server in the SDK background subsystem receives the security verification result information indicating that the security verification is passed
- the SDK background subsystem can call the preset query interface to transmit the payment information such as payer information, order number and other order information of this payment to the SDK server of the payment code subsystem.
- the SDK server of the payment code subsystem can further supplement this payment.
- Other order information such as merchant number and other payment information related to payment, etc., synchronize the payment information and order information to the host program server to realize the exchange of information about this payment between the SDK server in the SDK background system and the host program server. Synchronize.
- step S203 if the security verification result information indicates that the security verification is passed, a first notification message is sent to the SDK in the terminal device.
- the first notification message is used to instruct the SDK to notify the host program to display the user verification page to prompt the user to enter the first user verification input information.
- the first user verification input information is used by the host program server to perform user verification to obtain user verification result information.
- the SDK in the terminal device may send a message to the host program for instructing the host program to display the user verification page.
- the host program causes the terminal device to display the user authentication page.
- the user verification page may include a password filling area, a verification code filling area, a biometric collection area, etc.
- the method of user verification is not limited here.
- the information input by the user to the user verification page is the first user verification input information.
- the host program may send the first user authentication input information to the host program server.
- the host program server can perform user verification based on the received first user verification input information, and obtain user verification result information.
- User authentication is used to verify the identity of the user. Passed user verification means that the user performing the payment operation is a legitimate user.
- the first user's verification input information is a password
- the host program server verifies whether the first user's verification input information is consistent with the password registered by the user in the host program server. If they are consistent, the user verification passes; otherwise, the user verification fails.
- the first user verification input information is a face image
- the host program server verifies whether the first user verification input information and the face image reserved by the user in the host program server belong to the same user. If they belong to the same user, the user verification is passed; Otherwise, the user verification fails.
- User verification result information is used to indicate whether the user verification has passed.
- the host program server can feed back the user verification result information to the host program and SDK server respectively.
- the host program will also transmit the user verification result to the SDK, so that both the owner of the SDK and the owner of the host program can know whether the user verification has passed. .
- the SDK can add hidden information associated with the action of displaying the user verification page, so as to facilitate subsequent analysis and troubleshooting of the execution of the process of displaying the user verification page by the host program.
- step S204 if the user verification result information indicates that the user verification has passed, a payment request is initiated to complete the payment.
- the user verification result information indicates that the user has passed the verification, indicating that the user's identity is highly secure and can initiate a payment request to the payer's account management system and make the payment normally.
- the user verification result information indicates that the user verification has not passed and the payment can be suspended.
- consistency verification conditions may be used to verify the security of user verification result information during transmission.
- the consistency verification condition is used to determine whether the user verification result information is safe and valid during the transmission process.
- the user verification result information meets the consistency verification conditions, which means that the user verification result information is safe and effective during the transmission process.
- a payment request can be initiated to the payer's account management system and payment can be made normally, or the SDK server can send a request to the payer's account management system through the host program server.
- the payer's account management system initiates a payment request and makes the payment normally; the user verification result information does not meet the consistency verification conditions, which means that the user verification result information is not safe and valid during the transmission process, and the payment can be suspended.
- the consistency verification condition may include that the first user verification result information and the second user verification result information are consistent.
- the first user verification result information is the user verification result information transmitted by the host program server to the SDK through the host program.
- the second user verification result information is user verification result information obtained from the host program server.
- the first user verification result information is consistent with the second user verification result information, which means that the user verification result information is safe and effective during the transmission process; the first user verification result information is inconsistent with the second user verification result information, which means the user verification result information is inconsistent It is not safe and effective during transmission.
- the SDK server can obtain the payment result information, which indicates whether the payment was successful.
- the SDK server can transmit the payment result information to the SDK, merchant system, etc. to display the result of successful payment to the user, merchant, etc.
- the SDK can Control the terminal device to display the payment in progress logo, such as an image containing the word "loading", and stop displaying the payment in progress logo when the terminal device displays the payment completion page.
- the SDK server responds to the payment request message and sends a security verification request message to the security control system to request the security control system to perform security verification on this payment to complete the security requirements required by the SDK owner. verify.
- the SDK server sends a message to the SDK of the terminal device to instruct the SDK to notify the host program to display the user verification page, so that the SDK can trigger the host program to actively initiate user verification to complete the requirements of the host program owner. Verification of user identity security.
- two-way verification is realized between the SDK owner and the host program owner, which improves the security of the payment and meets the security control needs of the SDK owner and the host program owner.
- the SDK server may provide the first payment policy information of the SDK owner, and the first payment policy information may include the SDK owner's first payment policy information. Promotion information, payment activity information, etc., can be used to calculate the amount of the payment indicated by the payment request message.
- the host program server can provide second payment policy information of the party to which the host program belongs.
- the second payment strategy information can include preferential information, payment activity information, etc. of the party to which the host program belongs, and can be used to calculate the amount of the payment indicated by the payment request message.
- the SDK server can also directly query the host program server or query the host program server for payment policy information such as preferential information, payment activity information, etc. through the payment policy system.
- the information exchanged between the SDK and the host program is encrypted information, and the SDK needs to encrypt and decrypt the information.
- the SDK server stores keys used to encrypt and decrypt information exchanged between the SDK and the host program.
- the SDK server may request a user authentication method from the host program server, and transmit feedback from the host program server to the SDK, so that the SDK performs corresponding operations.
- Figure 3 is a flow chart of another embodiment of the payment method provided in the first aspect of this application. The difference between Fig. 3 and Fig. 2 is that the payment method shown in Fig. 3 may also include steps S205 to S208, and step S203 in Fig. 2 may be specifically refined into step S2031 in Fig. 3.
- step S205 if the security verification result information indicates that the security verification is passed, a user verification mode request message is sent to the host program server.
- the user verification method request message is used to request the user verification method from the host program server, and may include one or more of the order information, terminal device information, and payment information corresponding to the payment indicated by the payment request message.
- order information terminal device information
- payment information corresponding to the payment indicated by the payment request message.
- the host program server can determine the verification operation information based on the information in the user verification method request message.
- the verification operation information is used to indicate whether to perform user verification and the method of user verification.
- the host program server can store judgment conditions for determining whether to perform user verification and the method of user verification, and can determine whether to perform user verification and the method of user verification based on whether the information in the user verification method request message meets the reference conditions.
- the judgment conditions can be set according to payment scenarios, needs, etc., and are not limited here.
- the user verification method request message may include payment information
- the payment information may include the payment amount.
- the judgment conditions may include the correspondence between the payment amount range and whether to perform user verification and the user verification method.
- the judgment conditions include: the payment amount is less than 100 yuan, User verification is not required; when the payment amount is within the range of 100 yuan to 500 yuan, user verification is required, and the user verification method is password verification; when the payment amount is within the range of 500 yuan to 1,000 yuan, user verification is required, and The user verification method is verification code verification; if the payment amount is greater than 1,000 yuan, user verification is required, and the user verification method is biometric verification.
- the user verification method request message may include order information and payment information.
- the order information includes the order ID and the user account that placed the order, and the payment information includes the payer's login account.
- the judgment conditions may include: the user's account that placed the order is inconsistent with the payer's login account. , user verification is required, and the user verification method is biometric verification; the order user account is consistent with the payer's login account, user verification is required, and the user verification method is password verification.
- the host program server After the host program server determines the verification operation information, it can send a user verification method feedback message to the SDK server.
- the user verification method feedback message includes verification operation information.
- step S206 a user verification method feedback message sent by the host program server is received.
- step S207 if the verification operation information includes the payment rejection identifier, a second notification message is sent to the SDK.
- the payment refusal mark indicates that user verification is not required and payment is stopped.
- the SDK server sends second notification information to the SDK in the terminal device.
- the second notification message is used to instruct the SDK to issue a payment refusal prompt message.
- the SDK may issue a prompt message to remind the user that there is a payment risk.
- the prompt message causes the terminal device to display text such as "Host program risk is limited.”
- the user verification method feedback message may also include the reason for refusal of payment.
- the second notification information may also include the reason for refusal of payment.
- the prompt information sent by the SDK in response to the second notification information may include the reason for refusal of payment.
- the terminal device can display the reason for rejecting payment to inform the user.
- Reasons for payment refusal may include SDK exceptions, host program server exceptions, and other reasons that cause user verification method identification to fail.
- step S208 if the verification operation information includes the password-free payment identification, a third notification message is sent to the SDK.
- the password-free payment logo indicates that user verification is not required and the payment process can be continued.
- the SDK server sends third notification information to the SDK in the terminal device.
- the third notification message is used to instruct the SDK to issue a password-free payment prompt message.
- the password-free payment prompt information can remind the user that the payment is a password-free payment.
- step S2031 when the verification operation information includes the user verification method identifier and the security verification result information indicates that the security verification is passed, a first notification message is sent to the SDK.
- the first notification message includes a user verification method identifier.
- the user authentication method identifier is used to indicate the method of user authentication.
- the first notification message is used to instruct the SDK to notify the host program to display a user verification page that matches the user verification method identifier, so as to prompt the user to enter first user verification input information that matches the user verification method identifier. That is, in response to the first notification message, the SDK may send an instruction message including a user verification method identifier to the host program, and the host program displays a user verification page corresponding to the user verification method indicated by the user verification method identifier according to the user verification method identifier, corresponding to Specifically, the first user verification input information input by the user also corresponds to the user verification method indicated by the user verification method identifier.
- the user verification method is identified as 01
- the user verification method is password verification
- the user verification page displayed by the host program is a password verification page
- the first user verification input information that the user needs to enter is a password
- the user verification method is identified as 10
- the user The verification method is verification code verification.
- the user verification page displayed by the host program is the verification code verification page.
- the first user verification input information that the user needs to enter is the verification code
- the user verification method is identified as 11, and the user verification method is biometric verification.
- the user verification page displayed by the host program is a biometric verification page
- the first user verification input information that the user needs to input is biometric.
- the payment request message, the security verification request message, and the security verification result information may include a target host program identification.
- the target host program identifier includes the payment host program identifier corresponding to the payment request message, that is, the target host program identifier can represent the payment-related host program corresponding to the payment request message.
- the SDK server has the first corresponding relationship by default.
- the first corresponding relationship includes the relationship between the host program identifier and the user authentication caller.
- the host program ID is used to identify the host program.
- the user verification caller is used to indicate the subject that displays the user verification page.
- the user verification caller includes the SDK or host program in the terminal device.
- the SDK server can determine the target user verification caller corresponding to the target host program identification according to the target host program identification and the first corresponding relationship.
- the target user verification caller is the user verification caller corresponding to the target host program identifier in the first correspondence relationship.
- the SDK server sends a first notification message to the SDK.
- the SDK server sends a fourth notification message to the SDK.
- the fourth notification message is used to instruct the SDK to display a user verification page to prompt the user to enter second user verification input information.
- the second user verification input information is used by the SDK server to perform user verification to obtain user verification result information.
- the SDK in the terminal device may directly display the user verification page.
- the user verification is performed by the SDK server.
- the SDK in the terminal device may send the second user verification input information to the SDK server.
- the SDK server performs user verification based on the second user verification input information and obtains user verification result information.
- For the specific content of user verification please refer to the relevant description of user verification performed by the host program server in the above embodiment, which will not be described again here.
- the subject setting of user verification in the terminal device can be made more flexible and selective.
- the payment is initiated by the merchant system or through the merchant program installed in the terminal device.
- the order needs to be related between the merchant system and the SDK, and between the SDK and the SDK server. information interaction.
- 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 steps S209 to S211.
- step S209 an order identification is generated in response to the order request message sent by the merchant system.
- the merchant system can send an order request message to the SDK server to request an identifier that can identify the order, that is, an order identifier.
- the order identification generated by the SDK server can specifically be the order serial number.
- step S210 an order feedback message is sent to the merchant system, so that the merchant system sends an SDK call request message to the SDK.
- the SDK server can generate an order feedback message, which includes an order identifier.
- the SDK server sends the order feedback message to the merchant system, and the order feedback message includes the order identifier.
- the merchant system can send an SDK call request message to the SDK of the terminal device.
- the SDK call request includes the order identification.
- the SDK call request message is used to request to call the SDK in the terminal device.
- the SDK in the terminal device can collect information such as the geographical location of the terminal device and the terminal device identification.
- step S211 in response to the first order query message sent by the SDK, a first query feedback message is sent to the SDK.
- the SDK can send a first order query message to the SDK server, so that the SDK server can query the order information corresponding to the order ID through the order ID.
- the first order query message includes an order identification.
- the SDK server finds the order message corresponding to the order identifier, it feeds back the order message corresponding to the order identifier to the SDK through the first query feedback message.
- the first query feedback message includes order information corresponding to the order identification.
- the SDK can send a payment request message to the SDK server.
- the merchant can specify a specific payer for payment, and the order request message includes the identity information of the specified payer, that is, the specific payer is specified through the order request message.
- the payment request message sent by the SDK to the SDK server includes payment payer identity information such as user login account.
- the SDK server can send a request to the SDK when the specified payer identity information is inconsistent with the payment payer identity information indicated in the payment request message. Send a payment suspension notification message to cause the SDK to issue a payment reminder message.
- the payment prompt information can prompt the user to switch the user's login account and pay again.
- the payment prompt information can also prompt the user the reason for the suspension of payment.
- the payment prompt information is the words "The login account information does not match the information specified by the merchant and the payment cannot be made temporarily" displayed on the terminal device. .
- the payment may be a payment initiated by a user using a terminal device to scan another person's payment code.
- the SDK and the SDK server still need to interact with order-related information.
- Figure 5 is a flow chart of yet another embodiment of the payment method provided in the first aspect of this application. The difference between Figure 5 and Figure 2 is that the payment method shown in Figure 5 may also include step S212 and step S213.
- step S212 receive a second order query message sent by the SDK of the terminal device.
- the terminal device scans the payment code to obtain the first code information.
- the first code information is the code information read from the payment code.
- the SDK of the terminal device can send a second order query message to the SDK server.
- the second order query message is used to request the SDK server to query the order message corresponding to the first code information.
- the second order query message includes the first code information obtained by scanning the payment code by the terminal device.
- step S213 send a second query feedback message to the SDK.
- the SDK server searches for the order information corresponding to the first code information based on the first code information. After finding the order information corresponding to the first code information, the SDK server can generate a second query feedback message and send the second query feedback message to the SDK.
- the second query feedback message includes order information corresponding to the first code information.
- the SDK After receiving the second query feedback message, the SDK can determine the payment amount based on the user's input, generate a payment request message, and send the payment request message to the SDK server. After receiving the payment request message, the SDK server can determine whether the payment card indicated in the payment request message is available, and if the payment card is available, send a security verification request message to the security control system.
- the payment may be a payment initiated by the user using the terminal device to display the payment code and others using the payment acceptance terminal to scan the payment code.
- the SDK server Before the SDK server receives the payment request message, the SDK can apply for a payment code from the SDK server.
- Figure 6 is a flow chart of yet another embodiment of the payment method provided in the first aspect of this application. The difference between Figure 6 and Figure 2 is that the payment method shown in Figure 6 may also include step S214.
- step S214 in response to the received payment code application message, a payment code feedback message is sent to the SDK.
- the payment code application message is sent by the SDK. That is, the SDK in the terminal device can send a payment code application message to the SDK server, and the payment code application message is used to apply for a payment code from the SDK server.
- the SDK server allocates a payment code to the payment code application message and feeds the payment code back to the SDK through the payment code feedback message.
- the payment code feedback message includes the payment code.
- the SDK backend system includes the SDK backend subsystem and the payment code subsystem.
- the SDK can send a payment code application message to the SDK server in the SDK background subsystem.
- the SDK server in the SDK background subsystem forwards the payment code application message to the SDK server in the payment code subsystem.
- the SDK server in the payment code subsystem applies for the payment code.
- the message assigns a payment code and sends a payment code feedback message to the SDK server in the SDK background subsystem.
- the SDK server in the SDK background subsystem forwards the payment code feedback message to the SDK.
- the payment request message is generated by the payment acceptance device based on the scanned payment code.
- the SDK can display the payment code when making payment.
- the payment acceptance device scans the payment code and obtains the second code information.
- the second code information is the code information read from the payment code.
- the payment acceptance device may generate a payment request message based on the second code information, and send the payment request message to the SDK server.
- a second aspect of the present application provides a payment method, which is applied to a terminal device, that is, the payment method can be executed by the terminal device.
- the terminal device has SDK and host program.
- Figure 7 is a flow chart of an embodiment of the payment method provided in the second aspect of this application. As shown in Figure 7, the payment method may include steps S301 to S304.
- step S301 the first notification message sent by the SDK server is obtained through the SDK.
- the first notification message is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is obtained by the security control system performing security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- the security verification request message is sent by the SDK server in response to the received payment request message.
- step S302 in response to the first notification message, the host program is notified through the SDK to display the user verification page to prompt the user to enter the first user verification input information.
- step S303 the first user verification input information is fed back to the host program server through the host program.
- the first user verification input information is used by the host program server to perform user verification to obtain user verification result information.
- step S304 the user verification result information obtained from the host program server through the host program is sent to the SDK server through the SDK, so that the SDK server initiates a payment request to complete the payment when the user verification result information indicates that the user verification has passed.
- the user verification result information is also used to enable the SDK server to initiate a payment request when the user verification result information satisfies the consistency verification condition.
- the consistency verification condition includes: the first user verification result information is consistent with the second user verification result information, and the first user verification result information is the user verification result information transmitted to the SDK by the host program server through the host program.
- the second user verification result information is the user verification result information obtained from the host program server.
- the SDK server responds to the payment request message and sends a security verification request message to the security control system to request the security control system to perform security verification on this payment to complete the security requirements required by the SDK owner. verify.
- the SDK in the terminal device receives a message sent by the SDK server instructing the SDK to notify the host program to display the user verification page.
- the SDK responds to the message and triggers the host program to actively initiate user verification to complete the host process. Verification of user identity security required by the program owner.
- two-way verification is realized between the SDK owner and the host program owner, which improves the security of the payment and meets the security control needs of the SDK owner and the host program owner.
- the SDK server can request the user verification method from the host program server, and the SDK can obtain feedback from the host program server through the SDK server and perform corresponding operations.
- Figure 8 is a flow chart of another embodiment of the payment method provided in the second aspect of this application. The difference between Figure 8 and Figure 7 is that the payment method shown in Figure 8 may also include step S305 and step S306.
- step S305 in response to the second notification message received by the SDK, the rejection prompt information is sent through the SDK.
- the second notification message is sent by the SDK server when the verification operation information includes the payment rejection identifier.
- step S306 in response to the third notification message received by the SDK, the password-free payment prompt information is sent through the SDK.
- the third notification message is sent by the SDK server after verifying that the operation information includes the password-free payment identification.
- the user verification method feedback message includes verification operation information.
- the user authentication mode feedback message is sent by the host server in response to the user authentication mode request message.
- the user verification method request message is sent by the SDK server to the host program server when the security verification result information indicates that the security verification has passed.
- the user verification method request message includes one or more of the order information, terminal device information, and payment information corresponding to the payment indicated by the payment request message.
- the first notification message is sent by the SDK server when the verification operation information includes the user verification method identification.
- the first notification message includes a user verification method identifier, which is used to instruct the SDK to notify the host program to display a user verification page that matches the user verification method identifier, so as to prompt the user to enter first user verification input information that matches the user verification method identifier.
- the security verification result information includes a target host program identification.
- the target host program identification includes the payment host program identification corresponding to the payment request message.
- the first notification message is sent by the SDK server when the target user verifies that the calling party is the host program.
- the target user verification caller is the user verification caller that matches the target host program identification in the first correspondence relationship, and the target host program identification includes the paid host program identification corresponding to the payment request message.
- the first corresponding relationship includes the relationship between the host program identifier and the user authentication caller.
- the terminal device when the target user verifies that the calling party is the SDK, the terminal device obtains the fourth notification message sent by the SDK server through the SDK.
- the fourth notification message is sent by the SDK server when the target user verifies that the caller is the SDK.
- the terminal device calls the SDK to display the user verification page to prompt the user to enter the second user verification input information.
- the terminal device feeds back the second user verification input information to the SDK server through the SDK.
- the second user verification input information is used by the SDK server to perform user verification to obtain user verification result information.
- the payment is initiated by the merchant system or through the merchant program installed in the terminal device.
- the order needs to be related between the merchant system and the SDK, and between the SDK and the SDK server. information interaction.
- Figure 9 is a flow chart of yet another embodiment of the payment method provided in the second aspect of this application. The difference between Fig. 9 and Fig. 7 is that the payment method shown in Fig. 9 may also include steps S307 to S309.
- step S307 an SDK call request message is received through the SDK, and the SDK call request message is generated by the merchant system in response to the order feedback message.
- the order feedback message and the SDK call request message include the order identification.
- the order identifier is generated by the SDK server in response to the order request message sent by the merchant system.
- step S308 in response to the SDK call request message, a first order query message is sent to the SDK server through the SDK.
- step S309 the first query feedback message sent by the SDK server in response to the first order query message is received through the SDK.
- the first query feedback message includes order information corresponding to the order identification.
- the order request message includes designated payer identity information.
- the terminal device may send a payment prompt message through the SDK.
- the payment suspension notification message is sent by the SDK server when the specified payer identity information is inconsistent with the payer identity information of the payment indicated by the payment request message.
- the payment may be a payment initiated by a user using a terminal device to scan another person's payment code.
- the SDK and the SDK server still need to interact with order-related information.
- Figure 10 is a flow chart of yet another embodiment of the payment method provided in the second aspect of this application. The difference between Fig. 10 and Fig. 7 is that the payment method shown in Fig. 10 may also include steps S310 to S312.
- step 310 the payment code is scanned to obtain the first code information.
- step 311 a second order query message is sent to the SDK server through the SDK.
- the second order inquiry message includes the first code information.
- step 312 the second query feedback message sent by the SDK server is received through the SDK.
- the second query feedback message includes order information corresponding to the first code information.
- the payment may be a payment initiated by the user using the terminal device to display the payment code and others using the payment acceptance terminal to scan the payment code.
- the SDK server Before the SDK server receives the payment request message, the SDK can apply for a payment code from the SDK server.
- Figure 11 is a flow chart of yet another embodiment of the payment method provided in the second aspect of this application. The difference between Figure 11 and Figure 7 is that the payment method shown in Figure 11 may also include steps S313 to S315.
- step S313 the payment code application message is sent to the SDK server through the SDK.
- step S314 the payment code feedback message sent by the SDK server is received through the SDK.
- the payment code feedback message includes the payment code.
- step S315 the payment code is displayed.
- the payment code is used to be scanned by the payment acceptance device to generate a payment request message.
- the third aspect of this application provides a payment method, which is applied to the host program server, that is, the payment method can be executed by the host program server.
- Figure 12 is a flow chart of an embodiment of the payment method provided in the third aspect of this application. As shown in Figure 12, the payment method may include steps S401 to S403.
- step S401 the first user verification input information fed back by the terminal device through the host program is received.
- the first user verification input information is obtained after the SDK notifies the host program to display the user verification page in response to the first notification message.
- the first notification message is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is obtained by the security control system performing security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- the security verification request message is sent by the SDK server in response to the received payment request message.
- step S402 user verification is performed based on the first user verification input information to obtain user verification result information.
- step S403 the user verification result information is sent to the host program in the terminal device, and the user verification result information is transmitted to the SDK through the host program, so that the SDK sends the user verification result information to the SDK server.
- the user verification result information represents user verification. If passed, the SDK server initiates a payment request to complete the payment.
- the host program server can also send user verification result information to the SDK server, so that the SDK server can determine whether the user verification result information represents that the user verification has passed and the user verification result information satisfies the consistency verification condition. In this case, initiate a payment request to complete the payment.
- the consistency verification condition includes that the first user verification result information and the second user verification result information are consistent.
- the first user verification result information is the user verification result information transmitted by the host program server to the SDK through the host program
- the second user verification result information is the user verification result information obtained from the host program server.
- the SDK server responds to the payment request message and sends a security verification request message to the security control system to request the security control system to perform security verification on this payment to complete the security requirements required by the SDK owner. verify.
- the SDK server sends a message to the SDK of the terminal device instructing the SDK to notify the host program to display the user verification page, so that the SDK can trigger the host program to actively initiate user verification.
- the terminal device can receive the first user verification input information input by the user, and send the first user verification input information to the host program server.
- the host program server can complete the verification of user identity security required by the host program owner.
- two-way verification is realized between the SDK owner and the host program owner, which improves the security of the payment and meets the security control needs of the SDK owner and the host program owner.
- the host program server stores a key for encrypting and decrypting information exchanged between the host program and the SDK.
- a key for encrypting and decrypting information exchanged between the host program and the SDK please refer to the relevant description in the above embodiment and will not be described again here.
- the host program server can accept requests from the SDK server and provide user verification methods to the SDK server.
- the SDK can obtain feedback from the host program server through the SDK server and perform corresponding operations.
- Figure 13 is a flow chart of another embodiment of the payment method provided in the third aspect of this application. The difference between Figure 13 and Figure 12 is that the payment method shown in Figure 13 may also include step S404 and step S405.
- step S404 receive the user verification mode request message sent by the SDK server when the security verification result information indicates that the security verification is passed.
- the user verification method request message includes one or more of the order information, terminal device information, and payment information corresponding to the payment indicated by the payment request message.
- step S405 a user verification method feedback message is sent to the SDK server according to the user verification method request message.
- the user verification method feedback message includes verification operation information.
- the SDK server sends a second notification message to the SDK, and the second notification message is used to instruct the SDK to send payment refusal prompt information.
- the SDK server sends a third notification message to the SDK, and the third notification message is used to instruct the SDK to send password-free payment prompt information.
- the first notification message is sent by the SDK server when the verification operation information includes the user verification method identification.
- the first notification message includes a user verification method identifier, which is used to instruct the SDK to notify the host program to display a user verification page that matches the user verification method identifier, so as to prompt the user to enter first user verification input information that matches the user verification method identifier.
- the security verification result information includes the target host program identification.
- the target host program identification includes the payment host program identification corresponding to the payment request message.
- the first notification message is sent by the SDK server when the target user verifies that the calling party is the host program.
- the target user verification caller is the user verification caller that matches the target host program identifier in the first correspondence relationship.
- the target host program identification includes the payment host program identification corresponding to the payment request message.
- the first corresponding relationship includes the relationship between the host program identifier and the user authentication caller.
- FIG 14 is a flow chart of an example of the payment process provided by the embodiment of the present application.
- Terminal devices include SDK and host programs.
- the payment process includes steps S501 to S522.
- step S501 after the user places an order, the merchant system sends an order request message to the SDK server.
- step S502 the SDK server responds to the order request message and sends an order feedback message to the merchant system.
- the order feedback message may include an order identification generated by the SDK server.
- step S503 the merchant system sends an SDK call request message to the SDK in the terminal device.
- step S504 the SDK collects terminal device information.
- step S505 the SDK sends a first order query message to the SDK server.
- step S506 the SDK server feeds back the first query feedback message to the SDK.
- step S507 the SDK sends a payment request message to the SDK server.
- step S508 the SDK server sends a security verification request message to the security control system.
- step S509 the security control system performs security verification on the payment indicated by the payment request message.
- step S510 the security control system feeds back the security verification result information to the SDK server.
- step S511 if the security verification result information indicates that the security verification is passed, the SDK server sends a user verification mode request message to the host program server.
- step S512 the host program server responds to the user verification method request message and sends a user verification method feedback message to the SDK server.
- the user verification method feedback message includes the user verification method identification.
- step S513 the SDK server sends a first notification message to the SDK.
- the first notification message includes a user verification method identifier.
- step S514 the SDK transmits the user authentication mode identifier to the host program.
- step S515 the host program is triggered to display the user verification page that matches the user verification method identifier.
- step S516 the host program receives the first user verification input information input by the user, and sends the first user verification input information to the host program server.
- step S517 the host program server performs user verification based on the first user verification input information and obtains user verification result information.
- step S5128 the SDK server obtains user verification result information from the host program server.
- the user verification result information obtained directly by the SDK server from the host server is called the second user verification result information.
- step S519 the host program server sends user verification result information to the host program.
- step S520 the host program feeds back the user verification result information to the SDK.
- step S521 the SDK feeds back the user verification result information to the SDK server.
- the user verification result information obtained by the SDK server from the SDK is called the first user verification result information.
- step S522 when the first user verification result information and the second user verification result information are consistent, the SDK server initiates a payment request to complete the payment.
- FIG 15 is a flow chart of another example of the payment process provided by the embodiment of the present application.
- Terminal devices include SDK and host programs.
- the payment process may include steps S601 to S621.
- step S601 the terminal device scans the payment code to obtain the first code information, and the SDK sends a second order query message to the SDK server.
- the second order inquiry message includes the first code information.
- step S602 the SDK server sends a second query feedback message to the SDK.
- step S603 the SDK receives user input and determines the payment amount.
- step S604 the SDK sends a payment request message to the SDK server.
- step S605 the SDK server determines whether there is an available payment card.
- step S606 if there is an available payment card, the SDK server sends a security verification request message to the security control system.
- step S607 the security control system performs security verification on the payment indicated by the payment request message.
- step S608 the security control system feeds back the security verification result information to the SDK server.
- step S609 if the security verification result information indicates that the security verification is passed, the SDK server sends a user verification mode request message to the host program server.
- step S610 the host program server responds to the user verification method request message and sends a user verification method feedback message to the SDK server.
- the user verification method feedback message includes the user verification method identification.
- step S611 the SDK server sends a first notification message to the SDK.
- the first notification message includes a user verification method identifier.
- step S612 the SDK transmits the user authentication mode identifier to the host program.
- step S613 the host program is triggered to display the user verification page that matches the user verification method identifier.
- step S614 the host program receives the first user verification input information input by the user, and sends the first user verification input information to the host program server.
- step S615 the host program server performs user verification based on the first user verification input information and obtains user verification result information.
- step S616 the SDK server obtains user verification result information from the host program server.
- the user verification result information obtained directly by the SDK server from the host server is called the second user verification result information.
- step S617 the host program server sends user verification result information to the host program.
- step S618 the host program feeds back the user verification result information to the SDK.
- step S619 the SDK feeds back the user verification result information to the SDK server.
- the user verification result information obtained by the SDK server from the SDK is called the first user verification result information.
- step S620 when the first user verification result information and the second user verification result information are consistent, the SDK server initiates a payment request to the host program server.
- step S621 the host program server initiates a payment request to the payer's account management system to complete the payment.
- the payment is initiated by the payment acceptance terminal scanning a payment code displayed on the terminal device.
- Terminal devices include SDK and host programs.
- the SDK background system including the SDK background subsystem and the payment code subsystem as an example.
- the SDK server in the SDK background subsystem is called the first SDK server
- the SDK server in the payment code subsystem is called the third 2.
- Figure 16 is a flow chart of another example of the payment process provided by the embodiment of the present application. As shown in Figure 16, the payment process may include steps S701 to S723.
- step S701 the SDK in the terminal device sends a payment code application message to the second SDK server through the first SDK server.
- step S702 the second SDK server allocates a payment code and sends a payment code feedback message to the SDK through the first SDK server.
- the payment code feedback message includes the payment code.
- step S703 the payment acceptance terminal scans the payment code displayed on the terminal device, obtains the second code information, and sends a payment request message to the second SDK server.
- the second SDK server may send a payment policy query message to the host program server through the payment policy system.
- step S705 the host program server feeds back payment policy information to the second SDK server through the payment policy system.
- step S706 the second SDK server sends an additional processing request message to the first SDK server.
- the additional processing request message includes payment policy information.
- step S707 the first SDK server sends a security verification request message to the security control system.
- step S708 the security control system performs security verification on the payment indicated by the payment request message.
- step S709 the security control system feeds back the security verification result information to the first SDK server.
- step S710 the first SDK server synchronizes payment information, order information and other information to the host program server through the second SDK server.
- step S711 the first SDK server sends a user verification mode request message to the host program server through the second SDK server.
- step S712 the host program server sends a user verification method feedback message to the first SDK server through the second SDK server.
- the user verification method feedback message includes the user verification method identification.
- the first SDK server sends a first notification message to the SDK.
- the first notification message includes the user authentication method identification.
- step S714 the SDK transmits the user authentication mode identifier to the host program.
- step S715 the host program is triggered to display the user verification page that matches the user verification method identifier.
- step S716 the host program receives the first user verification input information input by the user, and sends the first user verification input information to the host program server.
- step S717 the host program server performs user verification based on the first user verification input information and obtains user verification result information.
- step S7108 the first SDK server obtains user verification result information from the host program server through the second SDK server.
- the user verification result information obtained by the SDK server from the host server through the second SDK server is called the second user verification result information.
- step S719 the host program server sends user verification result information to the host program.
- step S720 the host program feeds back the user verification result information to the SDK.
- step S721 the SDK feeds back the user verification result to the first SDK server.
- the user verification result information obtained by the first SDK server from the SDK is called first user verification result information. If the owner of the host program and the payment card are the same, jump to step S724; if the owner of the host program and the payment card are different, jump to step S725.
- step S722 when the first user verification result information and the second user verification result information are consistent, the first SDK server initiates a payment request to the payer account management system through the second SDK server and the host program server to complete the payment. .
- step S723 when the first user verification result information and the second user verification result information are consistent, the first SDK server initiates a payment request to the payer account management system through the second SDK server to complete the payment.
- the second SDK server can also interact with the payment strategy system to honor the payment strategy information.
- a fourth aspect of this application provides an SDK server.
- Figure 17 is a schematic structural diagram of an embodiment of the SDK server provided in the fourth aspect of this application.
- the SDK server 800 may include a sending module 801 and a receiving module 802.
- the sending module 801 may be configured to send a security verification request message to the security control system in response to the received payment request message.
- the security verification request message includes security verification information and is used to instruct the security control system to perform security verification on the payment corresponding to the payment request message based on the security verification information.
- the receiving module 802 may be used to receive the security verification result information sent by the security control system.
- the sending module 801 may also be configured to send a first notification message to the SDK in the terminal device when the security verification result information indicates that the security verification is passed.
- the terminal device has SDK and host program.
- the first notification message is used to instruct the SDK to notify the host program to display the user verification page to prompt the user to enter the first user verification input information.
- the first user verification input information is used by the host program server to perform user verification to obtain user verification result information.
- the sending module 801 can also be used to initiate a payment request to complete the payment when the user verification result information indicates that the user verification has passed.
- the sending module 801 may be used to initiate the payment request when the user verification result information satisfies the consistency verification condition.
- the consistency verification condition includes: the first user verification result information and the second user verification result information are consistent.
- the first user verification result information is the user verification result information transmitted by the host program server to the SDK through the host program.
- the second user verification result information is user verification result information obtained from the host program server.
- the SDK server responds to the payment request message and sends a security verification request message to the security control system to request the security control system to perform security verification on this payment to complete the security requirements required by the SDK owner. verify.
- the SDK server sends a message to the SDK of the terminal device to instruct the SDK to notify the host program to display the user verification page, so that the SDK can trigger the host program to actively initiate user verification to complete the requirements of the host program owner. Verification of user identity security.
- two-way verification is achieved between the SDK owner and the host program owner, which improves the security of the payment and meets the security control needs of the SDK owner and the host program owner.
- the SDK server stores keys used to encrypt and decrypt information exchanged between the SDK and the host program.
- the sending module 801 may also be configured to send a user verification mode request message to the host program server when the security verification result information indicates that the security verification is passed.
- the user verification method request message includes one or more of the order information, terminal device information, and payment information corresponding to the payment indicated by the payment request message.
- the receiving module 802 may also be configured to receive a user verification mode feedback message sent by the host program server.
- the user verification method feedback message includes verification operation information.
- the sending module 801 may also be configured to send a second notification message to the SDK when the verification operation information includes a payment rejection identifier.
- the second notification message is used to instruct the SDK to issue a payment refusal prompt message.
- the receiving module 802 may also be configured to send a third notification message to the SDK when the verification operation information includes the password-free payment identification.
- the third notification message is used to instruct the SDK to issue a password-free payment prompt message.
- the sending module 801 may be configured to: send a first notification message to the SDK when the verification operation information includes the user verification mode identifier.
- the first notification message includes a user verification method identifier, which is used to instruct the SDK to notify the host program to display a user verification page that matches the user verification method identifier, so as to prompt the user to enter first user verification input information that matches the user verification method identifier.
- the SDK server may also include a query module.
- the query module may be used to determine the target user verification calling party corresponding to the target host program identifier according to the target host program identifier and the preset first corresponding relationship.
- the first corresponding relationship includes the relationship between the host program identifier and the user authentication caller.
- the sending module 801 may be configured to send a first notification message to the SDK when the target user verifies that the calling party is the host program.
- the sending module 801 may also be configured to send a fourth notification message to the SDK when the target user verifies that the calling party is the SDK.
- the fourth notification message is used to instruct the SDK to display a user verification page to prompt the user to enter second user verification input information.
- the second user verification input information is used by the SDK server to perform user verification to obtain user verification result information.
- the SDK server 800 may also include an order identification generation module.
- the order identification generation module may be used to generate an order identification in response to an order request message sent by the merchant system.
- the sending module 801 can also be used to send an order feedback message to the merchant system, so that the merchant system sends an SDK call request message to the SDK.
- the order feedback message and the SDK call request message include the order identification.
- the sending module 801 may also be configured to send a first query feedback message to the SDK in response to the first order query message sent by the SDK.
- the first query feedback message includes order information corresponding to the order identification.
- the order request message includes designated payer identity information.
- the sending module 801 may also be configured to send a payment suspension notification message to the SDK when the designated payer identity information is inconsistent with the payer identity information of the payment indicated by the payment request message, so that the SDK issues payment prompt information.
- the receiving module 802 may also be configured to receive a second order query message sent by the SDK of the terminal device.
- the second order query message includes the first code information obtained by scanning the payment code by the terminal device.
- the sending module 801 may also be used to send a second query feedback message to the SDK.
- the second query feedback message includes order information corresponding to the first code information.
- the sending module 801 may also be configured to send a payment code feedback message to the SDK in response to the received payment code application message.
- the payment code application message is sent by the SDK.
- the payment code feedback message includes the payment code.
- the payment request message is generated by the payment acceptance device based on the scanned payment code.
- a fifth aspect of this application provides a terminal device.
- the terminal device has SDK and host program.
- FIG. 18 is a schematic structural diagram of an embodiment of the terminal device provided in the fifth aspect.
- the terminal device 900 may include a receiving module 901, a display module 902 and a sending module 903.
- the receiving module 901 can be used to obtain the first notification message sent by the SDK server through the SDK.
- the first notification message is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is obtained by the security control system performing security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- the security verification request message is sent by the SDK server in response to the received payment request message.
- the display module 902 may be configured to, in response to the first notification message, notify the host program to display the user verification page through the SDK to prompt the user to enter the first user verification input information.
- the sending module 903 may be configured to feed back the first user verification input information to the host program server through the host program.
- the first user verification input information is used by the host program server to perform user verification to obtain user verification result information.
- the sending module 903 can also be used to send the user verification result information obtained from the host program server through the host program to the SDK server through the SDK, so that the SDK server can initiate a payment request to complete the payment when the user verification result information indicates that the user has passed the verification.
- the user verification result information is also used to enable the SDK server to initiate the payment request when the user verification result information satisfies the consistency verification condition.
- the consistency verification condition includes: the first user verification result information and the second user verification result information are consistent.
- the first user verification result information is the user verification result information transmitted by the host program server to the SDK through the host program
- the second user verification result information is the user verification result information obtained from the host program server.
- the SDK server responds to the payment request message and sends a security verification request message to the security control system to request the security control system to perform security verification on this payment to complete the security requirements required by the SDK owner. verify.
- the SDK in the terminal device receives a message sent by the SDK server instructing the SDK to notify the host program to display the user verification page.
- the SDK responds to the message and triggers the host program to actively initiate user verification to complete the host process. Verification of user identity security required by the program owner.
- two-way verification is realized between the SDK owner and the host program owner, which improves the security of the payment and meets the security control needs of the SDK owner and the host program owner.
- the SDK has a security domain, and information in the SDK is stored in the security domain.
- the information exchanged between the SDK and the host program is encrypted information.
- the encryption and decryption keys in the SDK are stored in the SDK server.
- the encryption and decryption keys in the host program are stored in the host program server.
- the display module 902 may also be configured to send a rejection prompt message through the SDK in response to the second notification message received by the SDK.
- the second notification message is sent by the SDK server when the verification operation information includes the payment rejection identifier.
- the display module 902 may also be configured to send password-free payment prompt information through the SDK in response to the third notification message received by the SDK.
- the third notification message is sent by the SDK server after verifying that the operation information includes the password-free payment identification.
- the user verification method feedback message includes verification operation information.
- the user authentication mode feedback message is sent by the host server in response to the user authentication mode request message.
- the user verification method request message is sent by the SDK server to the host program server when the security verification result information indicates that the security verification has passed.
- the user verification method request message includes one or more of the order information, terminal device information, and payment information corresponding to the payment indicated by the payment request message.
- the first notification message is sent by the SDK server when the verification operation information includes the user verification method identification.
- the first notification message includes a user verification method identifier, which is used to instruct the SDK to notify the host program to display a user verification page that matches the user verification method identifier, so as to prompt the user to enter first user verification input information that matches the user verification method identifier.
- the security verification result information includes a target host program identification.
- the target host program identification includes the payment host program identification corresponding to the payment request message.
- the first notification message is sent by the SDK server when the target user verification caller is the host program.
- the target user verification caller is the user verification caller that matches the target host program identifier in the first correspondence relationship.
- the target host program The identification includes the payment host program identification corresponding to the payment request message, and the first correspondence includes the relationship between the host program identification and the user verification caller.
- the receiving module 901 may also be used to obtain the fourth notification message sent by the SDK server through the SDK.
- the fourth notification message is sent by the SDK server when the target user verifies that the caller is the SDK.
- the display module 902 may also be configured to, in response to the fourth notification message, call the SDK to display the user verification page to prompt the user to enter the second user verification input information.
- the sending module 903 can also be used to feed back the second user verification input information to the SDK server through the SDK.
- the second user verification input information is used by the SDK server to perform user verification to obtain user verification result information.
- the receiving module 901 may also be configured to receive an SDK call request message through the SDK.
- the SDK call request message is generated by the merchant system in response to the order feedback message.
- the order feedback message and the SDK call request message include the order identification.
- the order identifier is generated by the SDK server in response to the order request message sent by the merchant system.
- the sending module 903 may also be configured to send a first order query message to the SDK server through the SDK in response to the SDK call request message.
- the receiving module 901 may also be configured to receive, through the SDK, a first query feedback message sent by the SDK server in response to the first order query message.
- the first query feedback message includes order information corresponding to the order identification.
- the order request message includes designated payer identity information.
- the display module 902 may also be configured to send payment prompt information through the SDK in response to the payment suspension notification message received through the SDK.
- the payment suspension notification message is sent by the SDK server when the specified payer identity information is inconsistent with the payer identity information of the payment indicated by the payment request message.
- the terminal device 900 may further include a scanning module.
- the scanning module can be used to scan the payment code and obtain the first code information
- the sending module 903 can also be used to send a second order query message to the SDK server through the SDK.
- the second order inquiry message includes the first code information.
- the receiving module 901 may also be configured to receive the second query feedback message sent by the SDK server through the SDK.
- the second query feedback message includes order information corresponding to the first code information.
- the sending module 903 can also be used to send a payment code application message to the SDK server through the SDK.
- the receiving module 901 may also be configured to receive a payment code feedback message sent by the SDK server through the SDK, where the payment code feedback message includes the payment code.
- the display module 902 can also be used to display payment codes.
- the payment code is used to be scanned by the payment acceptance device to generate a payment request message.
- FIG. 19 is a schematic structural diagram of an embodiment of the host program server provided in the sixth aspect.
- the host program server 1000 may include a receiving module 1001, a verification module 1002, and a sending module 1003.
- the receiving module 1001 may be configured to receive first user verification input information fed back by the terminal device through the host program.
- the terminal device has a software development kit SDK and host program.
- the first user verification input information is obtained after the SDK notifies the host program to display the user verification page in response to the first notification message.
- the first notification message is sent by the SDK server based on the security verification result information indicating that the security verification has passed.
- the security verification result information is obtained by the security control system performing security verification on the payment corresponding to the payment request message based on the security verification information in the security verification request message.
- the security verification request message is sent by the SDK server in response to the received payment request message.
- the verification module 1002 may be used to perform user verification based on the first user verification input information and obtain user verification result information.
- the sending module 1003 can be used to send user verification result information to the host program in the terminal device, and transmit the user verification result information to the SDK through the host program, so that the SDK sends the user verification result information to the SDK server, where the user verification result information represents user verification. If passed, the SDK server initiates a payment request to complete the payment.
- the sending module 1003 can also be used to send user verification result information to the SDK server, so that the SDK server initiates payment when the user verification result information represents that the user verification has passed and the user verification result information satisfies the consistency verification condition. request to complete payment.
- the consistency verification condition includes that the first user verification result information and the second user verification result information are consistent.
- the first user verification result information is the user verification result information transmitted by the host program server to the SDK through the host program.
- the second user verification result information is user verification result information obtained from the host program server.
- the SDK server responds to the payment request message and sends a security verification request message to the security control system to request the security control system to perform security verification on this payment to complete the security requirements required by the SDK owner. verify.
- the SDK server sends a message to the SDK of the terminal device instructing the SDK to notify the host program to display the user verification page, so that the SDK can trigger the host program to actively initiate user verification.
- the terminal device can receive the first user verification input information input by the user, and send the first user verification input information to the host program server.
- the host program server can complete the verification of user identity security required by the host program owner.
- two-way verification is realized between the SDK owner and the host program owner, which improves the security of the payment and meets the security control needs of the SDK owner and the host program owner.
- the host program server stores keys used to encrypt and decrypt information exchanged between the host program and the SDK.
- the receiving module 1001 may also be configured to receive a user verification mode request message sent by the SDK server when the security verification result information indicates that the security verification is passed.
- the user verification method request message includes one or more of the order information, terminal device information, and payment information corresponding to the payment indicated by the payment request message.
- the sending module 1003 can also be used to send a user verification method feedback message to the SDK server according to the user verification method request message.
- the user verification method feedback message includes verification operation information.
- the SDK server when the verification operation information includes a payment refusal identifier, the SDK server sends a second notification message to the SDK, and the second notification message is used to instruct the SDK to issue payment refusal prompt information.
- the SDK server sends a third notification message to the SDK, and the third notification message is used to instruct the SDK to send password-free payment prompt information.
- the first notification message is sent by the SDK server when the verification operation information includes the user verification method identification.
- the first notification message includes a user verification method identifier, which is used to instruct the SDK to notify the host program to display a user verification page that matches the user verification method identifier, so as to prompt the user to enter first user verification input information that matches the user verification method identifier.
- the security verification result information includes a target host program identification.
- the target host program identification includes the payment host program identification corresponding to the payment request message.
- the first notification message is sent by the SDK server when the target user verifies that the calling party is the host program.
- the target user verification caller is the user verification caller that matches the target host program identifier in the first correspondence relationship.
- the target host program identification includes the payment host program identification corresponding to the payment request message.
- the first corresponding relationship includes the relationship between the host program identifier and the user authentication caller.
- the seventh aspect of this application provides an SDK server.
- Figure 20 is a schematic structural diagram of an embodiment of the SDK server provided in the seventh aspect of this application.
- the SDK server 1100 includes a memory 1101, a processor 1102, and a computer program stored on the memory 1101 and executable on the processor 1102.
- the above-mentioned processor 1102 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 1101 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 first aspect of the present application.
- the processor 1102 reads the executable program code stored in the memory 1101 to run a computer program corresponding to the executable program code, so as to implement the payment method in the embodiment of the first aspect.
- SDK server 1100 may also include communication interface 1103 and bus 1104. Among them, as shown in Figure 20, the memory 1101, the processor 1102, and the communication interface 1103 are connected through the bus 1104 and complete communication with each other.
- the communication interface 1103 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 1103.
- Bus 1104 includes hardware, software, or both, coupling the components of SDK server 1100 to each other.
- the bus 1104 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, Industry Standard Architecture (ISA) bus, infinite bandwidth interconnect, low pin count (LPC) bus, memory bus, MicroChannel 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 1104 may include one or more buses.
- the eighth aspect of this application provides a terminal device.
- the terminal device may include a memory, a processor, and a computer program stored in the memory and runable on the processor.
- a memory for the type and relationship between memory and processor, please refer to the relevant descriptions of memory and processor in the above SDK server.
- the differences from the above-mentioned SDK server include that when the software in the memory is executed, 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; and, the processor reads the memory by The executable program code stored in the computer is used 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.
- the terminal 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.
- the communication connection between the memory, processor, communication interface, and bus can be seen in the memory, processor, and communication interface in the SDK server shown in Figure 20. The communication connection with the bus will not be described again here.
- a ninth aspect of the present application provides a host program server.
- the host program server may include a memory, a processor, and a computer program stored in the memory and runable on the processor.
- the differences from the above-mentioned SDK server include that when the software in the memory is executed, 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; and, the processor reads the memory by The executable program code stored in the computer is used to run the computer program corresponding to the executable program code, so as to implement the payment method in the embodiment of the third aspect.
- the host program server 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.
- the communication connection between the memory, processor, communication interface, and bus can be seen in the memory, processor, and communication interface in the SDK server shown in Figure 20. The communication connection with the bus will not be described again here.
- a tenth aspect of the present application provides a payment system.
- the payment system may include the SDK server, terminal device and host program server in the above embodiments.
- the SDK server, terminal device and host program server please refer to the above embodiments. Relevant instructions will not be repeated here.
- An eleventh aspect of the present application also 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 of the first aspect in the above embodiment. , the second payment method and/or the third payment method, and can achieve the same technical effect, so to avoid duplication, they will not be described again 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.
- Embodiments of the present application may also provide a computer program product.
- the instructions in the computer program product can be executed by the processors of the SDK server, terminal device, and host program server, the SDK server, terminal device, and host program server execute the above-mentioned first step.
- 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
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请公开了一种支付方法、终端设备、服务器、系统及介质,属于数据处理领域。该方法包括:响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息,安全验证请求消息用于指示安全控制系统根据安全验证信息进行安全验证;接收安全控制系统发送的安全验证结果信息;在安全验证结果信息表征安全验证通过的情况下,向SDK发送第一通知消息,第一通知消息指示SDK通知宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息,第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息;在用户验证结果信息表征用户验证通过的情况下发起付款请求,以完成支付。
Description
相关申请的交叉引用
本申请要求享有于2022年03月10日提交的名称为“支付方法、终端设备、服务器、系统及介质”的中国专利申请202210238575.1的优先权,该申请的全部内容通过引用并入本文中。
本申请属于数据处理领域,尤其涉及一种支付方法、终端设备、服务器、系统及介质。
随着支付技术的发展,电子支付的应用越来越广泛。用户可通过终端设备实现支付。终端设备中安装有应用程序和软件开发工具包(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,以使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为本申请第四方面提供的SDK服务器的一实施例的结构示意图;
图18为第五方面提供的终端设备的一实施例的结构示意图;
图19为第六方面提供的宿主程序服务器的一实施例的结构示意图;
图20为本申请第七方面提供的SDK服务器的一实施例的结构示意图。
下面将详细描述本申请的各个方面的特征和示例性实施例,为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及具体实施例,对本申请进行进一步详细描述。应理解,此处所描述的具体实施例仅意在解释本申请,而不是限定本申请。对于本领域技术人员来说,本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。
随着支付技术的发展,电子支付的应用越来越广泛。用户可通过终端设备实现支付。终端设备中安装有用于支付的应用程序,但应用程序的功能有限,为了使得支付功能更加完善,终端设备中还可设置SDK,SDK可集成在应用程序中,和应用程序共同实现支付。在这种情况下,支付过程在终端设备中会涉及应用程序和SDK两个主体,支付过程涉及的主体增多,支付存在的安全风险也随之增大。因此,亟需一种能够提高安全性的支付方法。
本申请实施例提供一种支付方法、终端设备、服务器、系统及介质,能够分别以SDK和宿主程序为主体,进行双重验证,在SDK为主体的验证和宿主程序为主体的验证均通过的情况下,完成支付。通过SDK和宿主程序两方面的验证来保证SDK相关交互和宿主程序相关交互的安全性,从而提高整个支付过程的安全性。
本申请提供的支付方法应用于支付场景中,主要可涉及终端设备、SDK后台系统、宿主程序后台系统和安全控制系统。图1为本申请实施例提供的支付方法的应用场景的一示例的示意图。如图1所示,终端设备11可分别与SDK后台系统12、宿主程序后台系统13进行通信交互,SDK后台系统12还可分别与宿主程序后台系统13、安全控制系统14进行通信交互。
终端设备11具有宿主程序和SDK。终端设备11的支付功能需要宿主 程序调用SDK共同实现。终端设备11中的SDK与宿主程序之间可交互。终端设备11中的SDK可与SDK后台系统12通信交互,终端设备11中的宿主程序可与宿主程序后台系统13通信交互。终端设备11为用户用于进行支付的设备,具体可包括手机、平板电脑、电子计算机、只能穿戴设备等,在此并不限定。
SDK后台系统12为SDK的后台系统,可包括一台以上的SDK服务器,在此并不限定SDK后台系统12中SDK服务器的种类和数量。终端设备11在支付过程中,会通过SDK将支付相关的信息发送给SDK后台系统12。SDK后台系统12也可预先存储支付的用户的账户信息及个人信息等。
在一些实施例中,SDK后台系统12可包括SDK后台子系统和支付码子系统,SDK后台子系统与支付码子系统之间可通信交互,SDK后台子系统还可与终端设备11中的SDK通信交互,支付码子系统可与宿主程序后台系统通信交互。支付码子系统存储有支付码的相关信息,可对支付码进行管理和验证。支付码可包括收款码、付款码等,支付码具体可为二维码或其他形式的图形码,在此并不限定。
宿主程序后台系统13为宿主程序的后台系统,可包括一台以上的宿主程序服务器,在此并不限定宿主程序后台系统13中宿主程序服务器的种类和数量。终端设备11在支付过程中,会通过宿主程序与宿主程序后台系统13交互。宿主程序后台系统13还可与SDK后台系统12通信交互。
安全控制系统14可用于对支付进行安全验证,可包括一台以上的电子设备,在此并不限定安全控制系统14中电子设备的种类和数量。安全控制系统14可与SDK后台系统12通信交互。在SDK后台系统12包括SDK后台子系统和支付码子系统的情况下,安全控制系统14可与其中的SDK后台子系统通信交互。
在一些实施例中,终端设备11中SDK和宿主程序之间的信息传输为加密传输,即终端设备11中SDK和宿主程序之间交互的信息为加密信息。SDK和宿主程序中各自存储有加、解密所需的加、解密算法,SDK 和宿主程序中的加、解密算法可根据应用环境、需求等设定,例如,SDK和宿主程序中的加、解密算法可包括SM2算法、SM4算法、数据加密标准(Data Encryption Standard,DES)、RSA算法等,在此并不限定。SDK中加、解密算法所需的密钥可由SDK后台系统12存储和管理,即SDK中加、解密的密钥可存储于SDK后台系统12中的SDK服务器,SDK可通过与SDK后台系统12进行交互以实现加、解密。宿主程序中加、解密算法所需的密钥可由宿主程序后台系统13存储和管理,即宿主程序中加、解密的密钥存储于宿主程序后台系统13中的宿主程序服务器,宿主程序可通过与宿主程序后台系统13进行交互以实现加、解密。通过SDK与宿主程序之间的密文传输,SDK与宿主程序之间传输的信息不容易被窃取,可保证SDK与宿主程序之间的通信安全。
在一些实施例中,终端设备11中SDK可具有安全域,SDK中的信息可存储于安全域。安全域可为加密的数据存储空间,具体可通过硬件和/或软件实现,如通过安全元件(Secure Element,SE)和/或可信执行环境(TrustedExecutionEnvironment,TEE)等实现。SDK可对安全域的权限进行管理,如划分不可开放读取的数据和仅有宿主程序有权限读取的数据等。
下面对本申请中的支付方法、终端设备、服务器、系统及介质依次进行说明。
本申请第一方面提供一种支付方法,该支付方法应用于SDK服务器,即该支付方法可由SDK服务器执行。图2为本申请第一方面提供的支付方法的一实施例的流程图。如图2所示,该支付方法可包括步骤S201至步骤S204。
在步骤S201中,响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息。
支付请求消息用于发起支付。支付请求消息可由终端设备中的SDK向SDK服务器发送,或者,支付请求消息可由支付受理设备向SDK服务器发送。在SDK后台系统包括SDK后台子系统和支付码子系统的情况下,可由支付受理设备向支付码子系统中的SDK服务器发起支付,支付 码子系统中的SDK服务器再向SDK后台子系统中的SDK服务器发送支付请求消息。支付请求消息可包括订单信息、终端设备信息、支付信息等。订单信息可包括订单标识、订单发起方、订单明细、订单金额、订单时间等与订单关联的信息,在此并不限定。终端设备信息可包括对进行本次支付的终端设备的地理位置、设备标识等与终端设备关联的信息,在此并不限定。支付信息可包括支付付款方信息、支付收款方信息、支付金额、支付时间等与支付相关的信息,在此并不限定。支付收款方信息可包括商户名称、商户账户等信息,支付付款方信息可包括支付方账户、支付方支付卡信息、支付方标识等信息,在此并不限定。
安全验证请求消息包括安全验证信息。安全验证请求消息用于指示安全控制系统根据安全验证信息对支付请求消息对应的支付进行安全验证。安全验证信息可包括终端设备中SDK向SDK服务器发送的至少部分信息,安全验证信息还可包括SDK服务器中预存的与支付请求消息指示的支付付款方信息等,在此并不限定。例如,安全验证信息可包括支付卡卡号、支付方登录账号、支付方登录账号关联的手机号、支付卡关联的手机号、终端设备标识、终端设备的地理位置、支付金额、支付时间、支付卡的历史支付信息等信息中的一项或两项以上,安全验证信息还可包括其他能够进行安全性方面验证的信息,在此并不限定。
在一些示例中,在安全验证请求消息包括支付卡卡号的情况下,该支付卡卡号可以为终端设备中SDK提供的默认支付卡卡号,若用户在终端设备切换默认支付卡即默认支付卡卡号发生变化的情况下,SDK会向SDK服务器发送包括新的默认支付卡卡号的消息,SDK服务器会被触发向安全控制系统再次发送包括新的默认支付卡卡号的安全验证请求消息。也就是说,若用户在终端设备显示的付款详情页切换默认支付卡,对应地,SDK服务器会重新向安全控制系统发送包括切换后的默认支付卡卡号的安全验证请求消息。
安全控制系统接收到安全验证请求消息,根据安全验证请求消息中的安全验证信息进行安全验证。安全验证可对支付的合法性以及支付的终端设备的登录状态的安全性进行验证,具体可通过安全验证信息是否满足预 定的安全判定条件,来确定安全验证是否通过。安全判定条件可根据具体场景、需求等设定,在此并不限定。例如,安全验证信息包括本次支付的终端设备标识和支付卡的历史支付信息,支付卡的历史支付信息包括支付卡的历史支付中的终端设备标识,若本次支付的终端设备标识和支付卡的历史支付中的终端设备标识一致,则安全验证通过;反之,安全验证未通过。又例如,安全验证信息包括本次支付的终端设备的地理位置、支付时间和支付卡的历史支付信息,支付卡的历史支付信息包括支付卡最近一次支付的终端设备的地理位置和支付时间,若支付卡最近一吃支付的支付时间与本次支付的支付时间之间的时长小于预设时长,且支付卡最近一次支付的终端设备的地理位置与本次支付的终端设备的地理位置之间的距离大于预设距离,则安全验证未通过;反之,安全验证通过。还例如,安全验证信息包括支付方登录账号关联的手机号和支付卡关联的手机号,若支付方登录账号关联的手机号与支付卡关联的手机号一致,则安全验证通过;反之,则安全验证未通过。
在一些示例中,在安全风险度非常高的情况下,如账户余额不足、支付为非法支付等情况,才判定安全验证未通过。在安全风险度中、低,能够通过后续的用户验证来判断支付的安全的情况下,可判定安全验证通过。例如,安全验证信息包括本次支付的终端设备标识和支付卡的历史支付信息,支付卡的历史支付信息包括支付卡的历史支付中的终端设备标识,由于用户存在更换终端设备的可能性,若本次支付的终端设备标识和支付卡的历史支付中的终端设备标识不一致,也可视为安全验证通过,在后续过程中可通过用户验证判断是否为用户本人使用更换的终端设备进行支付。又例如,安全验证信息包括本次支付的支付金额和支付方账户余额,若本次支付的支付金额小于等于支付方账户余额,则安全验证通过;反之,安全验证未通过。
在一些示例中,SDK在接收到支付请求消息的情况下,若检测到当前登录的用户账号并未关联支付卡,可发出绑卡提示信息,以提示用户进入绑卡流程以绑定支付卡。在绑定支付卡后,SDK再向安全控制系统发送安全验证请求消息。
在步骤S202中,接收安全控制系统发送的安全验证结果信息。
安全控制系统根据安全验证信息进行安全验证,可得到对于本次支付即支付请求消息指示的支付的安全验证结果信息。安全验证结果信息用于表征安全验证是否通过。若安全验证结果信息表征安全验证未通过,SDK服务器可向终端设备中的SDK发送指示消息,以使SDK发出中止支付的弹窗信息。
在一些示例中,在SDK服务器接收到表征安全验证通过的安全验证结果信息后,终端设备中的SDK可调用预设的查询接口,将本次支付的如付款方信息等支付信息、订单号等订单信息等传输至SDK服务器,SDK服务器可进一步补充本次支付的如商户号等其他订单信息以及与付款相关的其他支付信息等,将支付信息、订单信息同步至宿主程序服务器,以实现SDK服务器与宿主程序服务器关于本次支付的信息的同步。
在一些示例中,在SDK后台系统包括SDK后台子系统和支付码子系统的情况下,在SDK后台子系统中的SDK服务器接收到表征安全验证通过的安全验证结果信息后,SDK后台子系统中的SDK服务器可可调用预设的查询接口,将本次支付的如付款方信息等支付信息、订单号等订单信息等传输至支付码子系统的SDK服务器,支付码子系统的SDK服务器可进一步补充本次支付的如商户号等其他订单信息以及与付款相关的其他支付信息等,将支付信息、订单信息同步至宿主程序服务器,以实现SDK后台系统中的SDK服务器与宿主程序服务器关于本次支付的信息的同步。
在步骤S203中,在安全验证结果信息表征安全验证通过的情况下,向终端设备中的SDK发送第一通知消息。
安全验证结果信息表征安全验证通过,则可再进行宿主程序的所属方的用户验证流程。第一通知消息用于指示SDK通知宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息。第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
终端设备中的SDK响应于第一通知消息,可向宿主程序发送用于指示宿主程序展示用户验证页面的消息。响应于该消息,宿主程序使终端设 备显示用户验证页面。用户验证页面可包括密码填写区、验证码填写区、生物特征采集区等,在此并不限定用户验证的方式。用户向用户验证页面输入的信息即为第一用户验证输入信息。宿主程序可向宿主程序服务器发送第一用户验证输入信息。宿主程序服务器可根据接收到的第一用户验证输入信息进行用户验证,并得到用户验证结果信息。用户验证用于验证用户的身份。用户验证通过表示进行支付操作的用户是合法的用户本人。例如,第一用户验证输入信息为密码,宿主程序服务器验证第一用户验证输入信息与宿主程序服务器中用户注册的密码是否一致,若一致,则用户验证通过;反之,则用户验证未通过。又例如,第一用户验证输入信息为人脸图像,宿主程序服务器验证第一用户验证输入信息与宿主程序服务器中用户预留的人脸图像是否属于同一用户,若属于同一用户,则用户验证通过;反之,则用户验证未通过。
用户验证结果信息用于表征用户验证是否通过。宿主程序服务器可将用户验证结果信息分别向宿主程序和SDK服务器反馈,宿主程序还会将用户验证结果传输给SDK,以使SDK的所属方和宿主程序的所属方均可得知用户验证是否通过。
在一些示例中,在宿主程序展示用户验证页面时,SDK可添加与展示用户验证页面这一动作关联的埋点信息,以便后续对宿主程序展示用户验证页面这一过程的执行情况的分析和排查。
在步骤S204中,在用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
用户验证结果信息表征用户验证通过,表示用户身份安全性较高,可向支付方账户管理系统发起付款请求,正常进行支付。用户验证结果信息表征用户验证未通过,可中止该支付。
在一些实施例中,由于用户验证结果信息在传输过程中可能被窃取或篡改,为了进一步保证支付安全,可通过一致性验证条件来对用户验证结果信息在传输过程中的安全性进行验证。在用户验证结果信息满足一致性验证条件的情况下,发起所述付款请求。一致性验证条件用于判断用户验证结果信息在传输过程中是否安全、有效。用户验证结果信息满足一致性 验证条件,表示用户验证结果信息在传输过程中是安全、有效的,可向支付方账户管理系统发起付款请求,正常进行支付,或者,由SDK服务器通过宿主程序服务器向支付方账户管理系统发起付款请求,正常进行支付;用户验证结果信息不满足一致性验证条件,表示用户验证结果信息在传输过程中并不安全、有效,可中止该支付。
在一些示例中,一致性验证条件可包括第一用户验证结果信息和第二用户验证结果信息一致。其中,第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给SDK的用户验证结果信息。第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。第一用户验证结果信息和第二用户验证结果信息一致,表示用户验证结果信息在传输过程中是安全、有效的;第一用户验证结果信息和第二用户验证结果信息不一致,表示用户验证结果信息在传输过程中并不安全、有效。
支付成功后,SDK服务器可获取付款结果信息,付款结果信息表征付款是否成功。SDK服务器可将付款结果信息传输给SDK、商户系统等,以将付款是否成功的结果展示给用户、商户等。
在上述支付过程中,用户验证通过后,由于用户验证结果信息的传输、付款、以及付款结果信息的传输都需要一定时间,终端设备不会立即显示支付完成页面,在这种情况下,SDK可控制终端设备显示付款中标识,如包含“loading”字样的图像,在终端设备显示支付完成页面时,停止显示付款中标识。
在本申请实施例中,SDK服务器响应于支付请求消息,向安全控制系统发送安全验证请求消息,以请求安全控制系统对本次支付进行安全验证,以完成SDK所属方所需的安全性方面的验证。在安全验证通过的情况下,SDK服务器向终端设备的SDK发送用于指示SDK通知宿主程序展示用户验证页面的消息,以使SDK能够触发宿主程序主动发起用户验证,以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了SDK所属方和宿主程序所属方两个主体的双向验证,提高了支付的安全性,也满足了SDK所属方和宿主程序所属方两个主体对安全性管控的需求。
在一些示例中,在SDK服务器通过宿主程序服务器向支付方账户管理系统发起付款请求的情况下,SDK服务器可提供SDK所属方的第一支付策略信息,第一支付策略信息可包括SDK所属方的优惠信息、支付活动信息等,可用于参与支付请求消息指示的支付的金额计算。宿主程序服务器可提供宿主程序所属方的第二支付策略信息,第二支付策略信息可包括宿主程序所属方的优惠信息、支付活动信息等,可用于参与支付请求消息指示的支付的金额计算。
在一些实施例中,SDK服务器也可在接收支付请求消息后,直接向宿主程序服务器或通过支付策略系统向宿主程序服务器查询优惠信息、支付活动信息等支付策略信息。
在上述实施例中,SDK与宿主程序之间交互的信息为加密信息,SDK需要对信息进行加、解密。对应地,SDK服务器存储有用于对SDK与宿主程序之间交互的信息进行加、解密的密钥。
在一些实施例中,SDK服务器可向宿主程序服务器请求用户验证方式,并将宿主程序服务器的反馈传输给SDK,以使SDK做出对应的操作。图3为本申请第一方面提供的支付方法的另一实施例的流程图。图3与图2的不同之处在于,图3所示的支付方法还可包括步骤S205至步骤S208,图2中的步骤S203可具体细化为图3中的步骤S2031。
在步骤S205中,在安全验证结果信息表征安全验证通过的情况下,向宿主程序服务器发送用户验证方式请求消息。
用户验证方式请求消息用于向宿主程序服务器请求用户验证方式,可包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。订单信息、终端设备信息和支付信息的具体内容可参见上述实施中的相关说明,在此不再赘述。
宿主程序服务器可根据用户验证方式请求消息中的信息,确定验证操作信息,验证操作信息用于指示是否进行用户验证以及用户验证的方式。宿主程序服务器可存储有用于确定是否进行用户验证以及用户验证的方式的判断条件,可通过用户验证方式请求消息中的信息是否满足参考条件来判断是否进行用户验证以及用户验证的方式。判断条件可根据支付场景、 需求等设置,在此并不限定。例如,用户验证方式请求消息可包括支付信息,支付信息包括支付金额,判断条件可包括支付金额范围与是否进行用户验证以及用户验证的方式的对应关系,如判断条件包括:支付金额小于100元,不需进行用户验证;支付金额在100元至500元的范围内,需进行用户验证,且用户验证的方式为密码验证;支付金额在500元至1000元的范围内,需进行用户验证,且用户验证的方式为验证码验证;支付金额大于1000元,需进行用户验证,且用户验证的方式为生物特征验证。又例如,用户验证方式请求消息可包括订单信息和支付信息,订单信息包括订单标识和下订单用户账号,支付信息包括付款方登录账号,判断条件可包括:下订单用户账号与付款方登录账号不一致,需进行用户验证,且用户验证方式为生物特征验证;下订单用户账号与付款方登录账号一致,需进行用户验证,且用户验证方式为密码验证。
宿主程序服务器确定验证操作信息后,可向SDK服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括验证操作信息。
在步骤S206中,接收宿主程序服务器发送的用户验证方式反馈消息。
在步骤S207中,在验证操作信息包括拒绝支付标识的情况下,向SDK发送第二通知消息。
拒绝支付标识表示不需进行用户验证且停止支付。响应于用户验证方式反馈信息,SDK服务器向终端设备中SDK发送第二通知信息。第二通知消息用于指示SDK发出拒绝支付提示信息。SDK响应于第二通知消息,可发出提示信息,以提示用户存在支付风险。例如,提示信息使终端设备显示“宿主程序风险受限”等文字。在一些示例中,用户验证方式反馈消息还可包括拒绝支付原因,对应地,第二通知信息也可包括该拒绝支付原因,SDK响应于第二通知信息发出的提示信息可包括该拒绝支付原因,终端设备可显示该决绝支付原因,以告知用户。拒绝支付原因可包括SDK异常、宿主程序服务器异常等导致用户验证方式标识失败的原因。
在步骤S208中,在验证操作信息包括免密支付标识的情况下,向SDK发送第三通知消息。
免密支付标识表示不需进行用户验证且可继续支付流程。响应于用户验证方式反馈信息,SDK服务器向终端设备中SDK发送第三通知信息。第三通知消息用于指示SDK发出免密支付提示信息。免密支付提示信息可提示用户该支付为免密方式的支付。
在步骤S2031中,在验证操作信息包括用户验证方式标识且安全验证结果信息表征安全验证通过的情况下,向SDK发送第一通知消息。
第一通知消息包括用户验证方式标识。用户验证方式标识用于指示用户验证的方式。第一通知消息用于指示SDK通知宿主程序展示与用户验证方式标识匹配的用户验证页面,以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。即SDK响应于第一通知消息,可向宿主程序发送包括用户验证方式标识的指示消息,宿主程序根据用户验证方式标识,展现与用户验证方式标识指示的用户验证的方式对应的用户验证页面,对应地,用户输入的第一用户验证输入信息也与用户验证方式标识指示的用户验证的方式对应。
例如,用户验证方式标识为01,用户验证的方式为密码验证,宿主程序展示的用户验证页面为密码验证页面,用户需输入的第一用户验证输入信息为密码;用户验证方式标识为10,用户验证的方式为验证码验证,宿主程序展示的用户验证页面为验证码验证页面,用户需输入的第一用户验证输入信息为验证码;用户验证方式标识为11,用户验证的方式为生物特征验证,宿主程序展示的用户验证页面为生物特征验证页面,用户需输入的第一用户验证输入信息为生物特征。
在一些实施例中,支付请求消息、安全验证请求消息和安全验证结果信息可包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识,即目标宿主程序标识可表征支付请求消息对应的支付关联的宿主程序。
SDK服务器预设有第一对应关系。第一对应关系包括宿主程序标识与用户验证调起方的关系。宿主程序标识用于标识宿主程序。用户验证调起方用于指示展示用户验证页面的主体,用户验证调起方包括终端设备中的SDK或宿主程序。在接收安全验证结果信息后,SDK服务器可根据目标 宿主程序标识和第一对应关系,确定与目标宿主程序标识对应的目标用户验证调起方。目标用户验证调起方为在第一对应关系中与目标宿主程序标识对应的用户验证调起方。
在目标用户验证调起方为宿主程序的情况下,SDK服务器向SDK发送第一通知消息。在目标用户验证调起方为SDK的情况下,SDK服务器向SDK发送第四通知消息。第四通知消息用于指示SDK展示用户验证页面,以提示用户输入第二用户验证输入信息。第二用户验证输入信息用于SDK服务器进行用户验证以得到用户验证结果信息。终端设备中的SDK响应于第四通知消息,可由SDK直接展示用户验证页面,对应地,用户验证由SDK服务器执行。终端设备中的SDK可向SDK服务器发送第二用户验证输入信息。SDK服务器根据第二用户验证输入信息进行用户验证,得到用户验证结果信息,用户验证的具体内容可参见上述实施例中宿主程序服务器进行的用户验证的相关说明,在此不再赘述。
通过第一对应关系的设置,可使终端设备中用户验证的主体设置更加灵活,具有更多选择性。
在一些实施例中,支付由商户系统或通过终端设备中安装的商户程序发起,在SDK服务器接收到支付请求消息前,商户系统与SDK之间、SDK与SDK服务器之间还需就订单的相关信息进行交互。图4为本申请第一方面提供的支付方法的又一实施例的流程图。图4与图2的不同之处在于,图4所示的支付方法还可包括步骤S209至步骤S211。
在步骤S209中,响应于商户系统发送的订单请求消息,生成订单标识。
在用户下单生成订单后,商户系统可向SDK服务器发送订单请求消息,以向SDK服务器请求能够标识该笔订单的标识即订单标识。SDK服务器生成的订单标识具体可为订单流水号。
在步骤S210中,向商户系统发送订单反馈消息,以使商户系统向SDK发送SDK调用请求消息。
SDK服务器可生成订单反馈消息,订单反馈消息包括订单标识。SDK服务器向商户系统发送该订单反馈消息,订单反馈消息包括订单标识。商 户系统接收到订单反馈消息后,可向终端设备的SDK发送SDK调用请求消息,SDK调用请求包括订单标识。SDK调用请求消息用于请求调用终端设备中的SDK。终端设备中的SDK在初始化的过程中,可采集终端设备的地理位置、终端设备标识等信息。
在步骤S211中,响应于SDK发送的第一订单查询消息,向SDK发送第一查询反馈消息。
SDK可向SDK服务器发送第一订单查询消息,以在SDK服务器通过订单标识查询订单标识对应的订单信息。第一订单查询消息包括订单标识。SDK服务器查找到与订单标识对应的订单消息后,通过第一查询反馈消息将与订单标识对应的订单消息反馈给SDK。第一查询反馈消息包括与订单标识对应的订单信息。SDK接收到第一查询反馈消息后,可向SDK服务器发送支付请求消息。
在一些实施例中,商户可指定特定的付款方付款,订单请求消息包括指定付款方身份信息,即通过订单请求消息制定特定的付款方。SDK向SDK服务器发送的支付请求消息包括如用户登录账号等支付的付款方身份信息,SDK服务器可在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下,向SDK发送支付中止通知消息,以使SDK发出支付提示信息。支付提示信息可提示用户切换用户登录账号重新支付,支付提示信息也可提示用户支付中止的原因,如支付提示信息为终端设备显示的“登录账号信息与商户指定信息不符,暂无法支付”等字样。
在一些实施例中,支付可为用户利用终端设备扫描他人的收款码发起的支付。在SDK服务器接收到支付请求消息前,SDK与SDK服务器之间还需就订单的相关信息进行交互。图5为本申请第一方面提供的支付方法的又另一实施例的流程图。图5与图2的不同之处在于,图5所示的支付方法还可包括步骤S212和步骤S213。
在步骤S212中,接收终端设备的SDK发送的第二订单查询消息。
终端设备扫描收款码,可得到第一码信息。第一码信息为从收款码中读取得到的码信息。终端设备的SDK可向SDK服务器发送第二订单查询 消息。第二订单查询消息用于向SDK服务器请求查询与第一码信息对应的订单消息。第二订单查询消息包括终端设备扫描收款码得到的第一码信息。
在步骤S213中,向SDK发送第二查询反馈消息。
SDK服务器根据第一码信息,查找与第一码信息对应的订单信息。在查找到与第一码信息对应的订单信息后,SDK服务器可生产第二查询反馈消息,并向SDK发送第二查询反馈消息。第二查询反馈消息包括与第一码信息对应的订单信息。
SDK接收到第二查询反馈消息后,可根据用户的输入确定支付金额,生成支付请求消息,向SDK服务器发送支付请求消息。SDK服务器在接收到支付请求消息后,可判断支付请求消息指示的支付的付款卡是否可用,在付款卡可用的情况下,向安全控制系统发送安全验证请求消息。
在一些实施例中,支付可为用户利用终端设备显示付款码,由他人利用支付受理终端扫描付款码发起的支付。在SDK服务器接收到支付请求消息前,SDK可向SDK服务器申请付款码。图6为本申请第一方面提供的支付方法的再一实施例的流程图。图6与图2的不同之处在于,图6所示的支付方法还可包括步骤S214。
在步骤S214中,响应于接收的付款码申请消息,向SDK发送付款码反馈消息。
付款码申请消息由SDK发送。即终端设备中的SDK可向SDK服务器发送付款码申请消息,付款码申请消息用于向SDK服务器申请付款码。SDK服务器为付款码申请消息分配付款码,并通过付款码反馈消息将付款码反馈给SDK。付款码反馈消息包括付款码。
在一些示例中,SDK后台系统包括SDK后台子系统和支付码子系统。SDK可向SDK后台子系统中的SDK服务器发送付款码申请消息,SDK后台子系统中的SDK服务器向支付码子系统中的SDK服务器转发付款码申请消息,支付码子系统中的SDK服务器为付款码申请消息分配付款码,并向SDK后台子系统中的SDK服务器发送付款码反馈消息,SDK后台子系统中的SDK服务器向SDK转发付款码反馈消息。
支付请求消息由支付受理设备基于扫描的付款码生成。SDK收到付款码反馈消息后,可在支付时显示付款码。支付受理设备扫描付款码,得到第二码信息,第二码信息为从付款码中读取得到的码信息。支付受理设备可基于第二码信息生成支付请求消息,并向SDK服务器发送支付请求消息。
本申请第二方面提供一种支付方法,该支付方法应用于终端设备,即该支付方法可由终端设备执行。终端设备具有SDK和宿主程序。图7为本申请第二方面提供的支付方法的一实施例的流程图。如图7所示,该支付方法可包括步骤S301至步骤S304。
在步骤S301中,通过SDK获取SDK服务器发送的第一通知消息。
第一通知消息是SDK服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的。安全验证请求消息由SDK服务器响应于接收的支付请求消息发送。
在步骤S302中,响应于第一通知消息,通过SDK通知宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息。
在步骤S303中,通过宿主程序向宿主程序服务器反馈第一用户验证输入信息。
第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
在步骤S304中,通过SDK向SDK服务器发送通过宿主程序从宿主程序服务器获取的用户验证结果信息,使SDK服务器在用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
在一些实施例中,用户验证结果信息还用于使SDK服务器在用户验证结果信息满足一致性验证条件的情况下,发起付款请求。
在一些示例中,一致性验证条件包括:第一用户验证结果信息和第二用户验证结果信息一致,第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给SDK的用户验证结果信息,第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
上述步骤S301至步骤S304的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在本申请实施例中,SDK服务器响应于支付请求消息,向安全控制系统发送安全验证请求消息,以请求安全控制系统对本次支付进行安全验证,以完成SDK所属方所需的安全性方面的验证。在安全验证通过的情况下,终端设备中的SDK接收到SDK服务器发送的用于指示SDK通知宿主程序展示用户验证页面的消息,SDK响应于该消息,触发宿主程序主动发起用户验证,以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了SDK所属方和宿主程序所属方两个主体的双向验证,提高了支付的安全性,也满足了SDK所属方和宿主程序所属方两个主体对安全性管控的需求。
在一些实施例中,SDK服务器可向宿主程序服务器请求用户验证方式,SDK可通过SDK服务器获取宿主程序服务器的反馈,并做出对应的操作。图8为本申请第二方面提供的支付方法的另一实施例的流程图。图8与图7的不同之处在于,图8所示的支付方法还可包括步骤S305和步骤S306。
在步骤S305中,响应于SDK接收的第二通知消息,通过SDK发出拒绝提示信息。
第二通知消息由SDK服务器在验证操作信息包括拒绝支付标识的情况下发送。
在步骤S306中,响应于SDK接收的第三通知消息,通过SDK发出免密支付提示信息。
第三通知消息由SDK服务器在验证操作信息包括免密支付标识的情况下发送。
用户验证方式反馈消息包括验证操作信息。用户验证方式反馈消息由宿主服务器响应于用户验证方式请求消息发送。用户验证方式请求消息由SDK服务器在安全验证结果信息表征安全验证通过的情况下向宿主程序服务器发送。用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
在一些实施例中,第一通知消息由SDK服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识,用于指示SDK通知宿主程序展示与用户验证方式标识匹配的用户验证页面,以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
上述步骤S305和步骤S306的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一通知消息由SDK服务器在目标用户验证调起方为宿主程序的情况下发送。目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方,目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一对应关系包括宿主程序标识与用户验证调起方的关系。
在一些实施例中,在目标用户验证调起方为SDK的情况下,终端设备通过SDK获取SDK服务器发送的第四通知消息。第四通知消息由SDK服务器在目标用户验证调起方为SDK的情况下发送。终端设备响应于第四通知消息,调用SDK展示用户验证页面,以提示用户输入第二用户验证输入信息。终端设备通过SDK向SDK服务器反馈第二用户验证输入信息。第二用户验证输入信息用于SDK服务器进行用户验证以得到用户验证结果信息。
在一些实施例中,支付由商户系统或通过终端设备中安装的商户程序发起,在SDK服务器接收到支付请求消息前,商户系统与SDK之间、SDK与SDK服务器之间还需就订单的相关信息进行交互。图9为本申请第二方面提供的支付方法的又一实施例的流程图。图9与图7的不同之处在于,图9所示的支付方法还可包括步骤S307至步骤S309。
在步骤S307中,通过SDK接收SDK调用请求消息,SDK调用请求消息由商户系统响应于订单反馈消息生成。
订单反馈消息和SDK调用请求消息包括订单标识。订单标识由SDK服务器响应于商户系统发送的订单请求消息生成。
在步骤S308中,响应于SDK调用请求消息,通过SDK向SDK服务 器发送第一订单查询消息。
在步骤S309中,通过SDK接收SDK服务器响应于第一订单查询消息发送的第一查询反馈消息。
第一查询反馈消息包括与订单标识对应的订单信息。
在一些实施例中,订单请求消息包括指定付款方身份信息。响应于通过SDK接收的支付中止通知消息,终端设备可通过SDK发出支付提示信息。支付中止通知消息由SDK服务器在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下发送。
上述步骤S307至步骤S309的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,支付可为用户利用终端设备扫描他人的收款码发起的支付。在SDK服务器接收到支付请求消息前,SDK与SDK服务器之间还需就订单的相关信息进行交互。图10为本申请第二方面提供的支付方法的又另一实施例的流程图。图10与图7的不同之处在于,图10所示的支付方法还可包括步骤S310至步骤S312。
在步骤310中,扫描付款码,得到第一码信息。
在步骤311中,通过SDK向SDK服务器发送第二订单查询消息。
第二订单查询消息包括第一码信息。
在步骤312中,通过SDK接收SDK服务器发送的第二查询反馈消息。
第二查询反馈消息包括与第一码信息对应的订单信息。
上述步骤S310至步骤S312的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些实施例中,支付可为用户利用终端设备显示付款码,由他人利用支付受理终端扫描付款码发起的支付。在SDK服务器接收到支付请求消息前,SDK可向SDK服务器申请付款码。图11为本申请第二方面提供的支付方法的再一实施例的流程图。图11与图7的不同之处在于,图11所示的支付方法还可包括步骤S313至步骤S315。
在步骤S313中,通过SDK向SDK服务器发送付款码申请消息。
在步骤S314中,通过SDK接收SDK服务器发送的付款码反馈消息。
付款码反馈消息包括付款码。
在步骤S315中,显示付款码。
付款码用于被支付受理设备扫描以生成支付请求消息。
上述步骤S313至步骤S315的具体内容可参见上述实施例中的相关说明,在此不再赘述。
本申请第三方面提供一种支付方法,应用于宿主程序服务器,即该支付方法可由宿主程序服务器执行。图12为本申请第三方面提供的支付方法的一实施例的流程图。如图12所示,该支付方法可包括步骤S401至步骤S403。
在步骤S401中,接收终端设备通过宿主程序反馈的第一用户验证输入信息。
第一用户验证输入信息在SDK响应于第一通知消息通知宿主程序展示用户验证页面后得到。第一通知消息是SDK服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的。安全验证请求消息由SDK服务器响应于接收的支付请求消息发送。
在步骤S402中,根据第一用户验证输入信息进行用户验证,得到用户验证结果信息。
在步骤S403中,向终端设备中的宿主程序发送用户验证结果信息,通过宿主程序将用户验证结果信息传输给SDK,以使SDK向SDK服务器发送用户验证结果信息,在用户验证结果信息表征用户验证通过的情况下,使SDK服务器发起付款请求,以完成支付。
在一些实施例中,在执行步骤S403之后,宿主程序服务器还可向SDK服务器发送用户验证结果信息,以使SDK服务器在用户验证结果信息表征用户验证通过且用户验证结果信息满足一致性验证条件的情况下,发起付款请求,以完成支付。
在一些示例中,一致性验证条件包括第一用户验证结果信息和第二用户验证结果信息一致。第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给SDK的用户验证结果信息,第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
上述步骤S401至步骤S403的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在本申请实施例中,SDK服务器响应于支付请求消息,向安全控制系统发送安全验证请求消息,以请求安全控制系统对本次支付进行安全验证,以完成SDK所属方所需的安全性方面的验证。在安全验证通过的情况下,SDK服务器向终端设备的SDK发送用于指示SDK通知宿主程序展示用户验证页面的消息,以使SDK能够触发宿主程序主动发起用户验证。终端设备可接收用户输入的第一用户验证输入信息,并将第一用户验证输入信息向宿主程序服务器发送,宿主程序服务器可完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了SDK所属方和宿主程序所属方两个主体的双向验证,提高了支付的安全性,也满足了SDK所属方和宿主程序所属方两个主体对安全性管控的需求。
在上述实施例中,宿主程序服务器存储有用于对宿主程序与SDK之间交互的信息进行加、解密的密钥,具体内容可参见上述实施例中的现关说明,在此不再赘述。
在一些实施例中,宿主程序服务器可接受SDK服务器的请求,向SDK服务器提供用户验证方式,SDK可通过SDK服务器获取宿主程序服务器的反馈,并做出对应的操作。图13为本申请第三方面提供的支付方法的另一实施例的流程图。图13与图12的不同之处在于,图13所示的支付方法还可包括步骤S404和步骤S405。
在步骤S404中,接收SDK服务器在安全验证结果信息表征安全验证通过的情况下发送的用户验证方式请求消息。
用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
在步骤S405中,根据用户验证方式请求消息,向SDK服务器发送用 户验证方式反馈消息。
用户验证方式反馈消息包括验证操作信息。
在验证操作信息包括拒绝支付标识的情况下,SDK服务器向SDK发送第二通知消息,第二通知消息用于指示SDK发出拒绝支付提示信息。在验证操作信息包括免密支付标识的情况下,SDK服务器向SDK发送第三通知消息,第三通知消息用于指示SDK发出免密支付提示信息。
在一些实施例中,第一通知消息由SDK服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识,用于指示SDK通知宿主程序展示与用户验证方式标识匹配的用户验证页面,以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
上述步骤S404和步骤S405的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在一些示例中,安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一通知消息由SDK服务器在目标用户验证调起方为宿主程序的情况下发送。目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一对应关系包括宿主程序标识与用户验证调起方的关系。
为了便于说明,下面分别以支付由商户系统或通过终端设备中安装的商户程序发起、支付由终端设备扫描他人的收款码发起、支付由支付受理终端扫描付款码发起三种场景为例,对终端设备、系统、服务器之间的支付流程的交互进行说明。
在该示例中,支付由商户系统或通过终端设备中安装的商户程序发起。图14为本申请实施例提供的支付流程的一示例的流程图。终端设备包括SDK和宿主程序。如图14所示,该支付流程包括步骤S501至步骤S522。
在步骤S501中,用户下单后,商户系统向SDK服务器发送订单请求消息。
在步骤S502中,SDK服务器响应于订单请求消息,向商户系统发送 订单反馈消息。订单反馈消息可包括SDK服务器生成的订单标识。
在步骤S503中,商户系统向终端设备中SDK发送SDK调用请求消息。
在步骤S504中,SDK采集终端设备信息。
在步骤S505中,SDK向SDK服务器发送第一订单查询消息。
在步骤S506中,SDK服务器向SDK反馈第一查询反馈消息。
在步骤S507中,SDK向SDK服务器发送支付请求消息。
在步骤S508中,SDK服务器向安全控制系统发送安全验证请求消息。
在步骤S509中,安全控制系统对支付请求消息指示的支付进行安全验证。
在步骤S510中,安全控制系统向SDK服务器反馈安全验证结果信息。
在步骤S511中,在安全验证结果信息表征安全验证通过的情况下,SDK服务器向宿主程序服务器发送用户验证方式请求消息。
在步骤S512中,宿主程序服务器响应于用户验证方式请求消息,向SDK服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括用户验证方式标识。
在步骤S513中,SDK服务器向SDK发送第一通知消息。第一通知消息包括用户验证方式标识。
在步骤S514中,SDK向宿主程序传输用户验证方式标识。
在步骤S515中,宿主程序被触发,展示与用户验证方式标识匹配的用户验证页面。
在步骤S516中,宿主程序接收用户输入的第一用户验证输入信息,向宿主程序服务器发送第一用户验证输入信息。
在步骤S517中,宿主程序服务器根据第一用户验证输入信息进行用户验证,得到用户验证结果信息。
在步骤S518中,SDK服务器从宿主程序服务器获取用户验证结果信息。为了便于说明,将SDK服务器直接从宿主服务器获取到的用户验证 结果信息称为第二用户验证结果信息。
在步骤S519中,宿主程序服务器向宿主程序发送用户验证结果信息。
在步骤S520中,宿主程序将用户验证结果信息反馈给SDK。
在步骤S521中,SDK将用户验证结果信息反馈给SDK服务器。为了便于说明,将SDK服务器从SDK获取到的用户验证结果信息称为第一用户验证结果信息。
在步骤S522中,在第一用户验证结果信息和第二用户验证结果信息一致的情况下,SDK服务器发起付款请求,以完成支付。
上述步骤S501至步骤S522的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在该示例中,支付由终端设备扫描他人的收款码发起。图15为本申请实施例提供的支付流程的另一示例的流程图。终端设备包括SDK和宿主程序。如图15所示,该支付流程可包括步骤S601至步骤S621。
在步骤S601中,终端设备扫描收款码,得到第一码信息,SDK向SDK服务器发送第二订单查询消息。第二订单查询消息包括第一码信息。
在步骤S602中,SDK服务器向SDK发送第二查询反馈消息。
在步骤S603中,SDK接收用户输入,确定支付金额。
在步骤S604中,SDK向SDK服务器发送支付请求消息。
在步骤S605中,SDK服务器判断是否有可用的付款卡。
在步骤S606中,在存在可用的付款卡的情况下,SDK服务器向安全控制系统发送安全验证请求消息。
在步骤S607中,安全控制系统对支付请求消息指示的支付进行安全验证。
在步骤S608中,安全控制系统向SDK服务器反馈安全验证结果信息。
在步骤S609中,在安全验证结果信息表征安全验证通过的情况下,SDK服务器向宿主程序服务器发送用户验证方式请求消息。
在步骤S610中,宿主程序服务器响应于用户验证方式请求消息,向 SDK服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括用户验证方式标识。
在步骤S611中,SDK服务器向SDK发送第一通知消息。第一通知消息包括用户验证方式标识。
在步骤S612中,SDK向宿主程序传输用户验证方式标识。
在步骤S613中,宿主程序被触发,展示与用户验证方式标识匹配的用户验证页面。
在步骤S614中,宿主程序接收用户输入的第一用户验证输入信息,向宿主程序服务器发送第一用户验证输入信息。
在步骤S615中,宿主程序服务器根据第一用户验证输入信息进行用户验证,得到用户验证结果信息。
在步骤S616中,SDK服务器从宿主程序服务器获取用户验证结果信息。为了便于说明,将SDK服务器直接从宿主服务器获取到的用户验证结果信息称为第二用户验证结果信息。
在步骤S617中,宿主程序服务器向宿主程序发送用户验证结果信息。
在步骤S618中,宿主程序将用户验证结果信息反馈给SDK。
在步骤S619中,SDK将用户验证结果信息反馈给SDK服务器。为了便于说明,将SDK服务器从SDK获取到的用户验证结果信息称为第一用户验证结果信息。
在步骤S620中,在第一用户验证结果信息和第二用户验证结果信息一致的情况下,SDK服务器向宿主程序服务器发起付款请求。
在步骤S621中,宿主程序服务器向付款方账户管理系统发起付款请求,以完成支付。
上述步骤S601至步骤S621的具体内容可参见上述实施例中的相关说明,在此不再赘述。
在该示例中,支付由支付受理终端扫描终端设备显示的付款码发起。终端设备包括SDK和宿主程序。这里以SDK后台系统包括SDK后台子系统和支付码子系统为例进行说明,为了便于说明,将SDK后台子系统中 的SDK服务器称为第一SDK服务器,将支付码子系统中的SDK服务器称为第二SDK服务器。图16为本申请实施例提供的支付流程的又一示例的流程图。如图16所示,该支付流程可包括步骤S701至步骤S723。
在步骤S701中,终端设备中SDK通过第一SDK服务器向第二SDK服务器发送付款码申请消息。
在步骤S702中,第二SDK服务器分配付款码,并通过第一SDK服务器向SDK发送付款码反馈消息。付款码反馈消息包括付款码。
在步骤S703中,支付受理终端扫描终端设备显示的付款码,得到第二码信息,向第二SDK服务器发送支付请求消息。
在步骤S704中,第二SDK服务器可通过支付策略系统向宿主程序服务器发送支付策略查询消息。
在步骤S705中,宿主程序服务器通过支付策略系统向第二SDK服务器反馈支付策略信息。
在步骤S706中,第二SDK服务器向第一SDK服务器发送附加处理请求消息。附加处理请求消息包括支付策略信息。
在步骤S707中,第一SDK服务器向安全控制系统发送安全验证请求消息。
在步骤S708中,安全控制系统对支付请求消息指示的支付进行安全验证。
在步骤S709中,安全控制系统向第一SDK服务器反馈安全验证结果信息。
在步骤S710中,第一SDK服务器通过第二SDK服务器将支付信息、订单信息等信息同步至宿主程序服务器。
在步骤S711中,第一SDK服务器通过第二SDK服务器向宿主程序服务器发送用户验证方式请求消息。
在步骤S712中,宿主程序服务器通过第二SDK服务器向第一SDK服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括用户验证方式标识。
在步骤S713中,第一SDK服务器向SDK发送第一通知消息。第一 通知消息包括用户验证方式标识。
在步骤S714中,SDK向宿主程序传输用户验证方式标识。
在步骤S715中,宿主程序被触发,展示与用户验证方式标识匹配的用户验证页面。
在步骤S716中,宿主程序接收用户输入的第一用户验证输入信息,向宿主程序服务器发送第一用户验证输入信息。
在步骤S717中,宿主程序服务器根据第一用户验证输入信息进行用户验证,得到用户验证结果信息。
在步骤S718中,第一SDK服务器通过第二SDK服务器从宿主程序服务器获取用户验证结果信息。为了便于说明,将SDK服务器通过第二SDK服务器从宿主服务器获取到的用户验证结果信息称为第二用户验证结果信息。
在步骤S719中,宿主程序服务器向宿主程序发送用户验证结果信息。
在步骤S720中,宿主程序将用户验证结果信息反馈给SDK。
在步骤S721中,SDK将用户验证结果反馈给第一SDK服务器。为了便于说明,将第一SDK服务器从SDK获取到的用户验证结果信息称为第一用户验证结果信息。若宿主程序的所属方与付款卡所属方相同,跳转步骤S724;若宿主程序的所属方与付款卡所属方不同,跳转步骤S725
在步骤S722中,在第一用户验证结果信息和第二用户验证结果信息一致的情况下,第一SDK服务器通过第二SDK服务器和宿主程序服务器向付款方账户管理系统发起付款请求,以完成支付。
在步骤S723中,在第一用户验证结果信息和第二用户验证结果信息一致的情况下,第一SDK服务器通过第二SDK服务器向付款方账户管理系统发起付款请求,以完成支付。
在上述步骤S722和步骤S723之前,若支付使用了支付策略信息,第二SDK服务器还可与支付策略系统交互以承兑支付策略信息。
上述步骤S701至步骤S723的具体内容可参见上述实施例中的相关说明,在此不再赘述。
本申请第四方面提供一种SDK服务器。图17为本申请第四方面提供的SDK服务器的一实施例的结构示意图。如图17所示,该SDK服务器800可包括发送模块801和接收模块802。
发送模块801可用于响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息。
安全验证请求消息包括安全验证信息,用于指示安全控制系统根据安全验证信息对支付请求消息对应的支付进行安全验证。
接收模块802可用于接收安全控制系统发送的安全验证结果信息。
发送模块801还可用于在安全验证结果信息表征安全验证通过的情况下,向终端设备中的SDK发送第一通知消息。
终端设备具有SDK和宿主程序。第一通知消息用于指示SDK通知宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息。第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
发送模块801还可用于在用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
在一些实施例中,发送模块801可用于在用户验证结果信息满足一致性验证条件的情况下,发起所述付款请求。
在一些示例中,一致性验证条件包括:第一用户验证结果信息和第二用户验证结果信息一致。
第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给SDK的用户验证结果信息。第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
在本申请实施例中,SDK服务器响应于支付请求消息,向安全控制系统发送安全验证请求消息,以请求安全控制系统对本次支付进行安全验证,以完成SDK所属方所需的安全性方面的验证。在安全验证通过的情况下,SDK服务器向终端设备的SDK发送用于指示SDK通知宿主程序展示用户验证页面的消息,以使SDK能够触发宿主程序主动发起用户验证,以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过 程中实现了SDK所属方和宿主程序所属方两个主体的双向验证,提高了支付的安全性,也满足了SDK所属方和宿主程序所属方两个主体对安全性管控的需求。
在一些示例中,SDK服务器存储有用于对SDK与宿主程序之间交互的信息进行加、解密的密钥。
在一些实施例中,发送模块801还可用于在安全验证结果信息表征安全验证通过的情况下,向宿主程序服务器发送用户验证方式请求消息。
用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
接收模块802还可用于接收宿主程序服务器发送的用户验证方式反馈消息。
用户验证方式反馈消息包括验证操作信息。
发送模块801还可用于在验证操作信息包括拒绝支付标识的情况下,向SDK发送第二通知消息。
第二通知消息用于指示SDK发出拒绝支付提示信息。
接收模块802还可用于在验证操作信息包括免密支付标识的情况下,向SDK发送第三通知消息。
第三通知消息用于指示SDK发出免密支付提示信息。
在一些实施例中,发送模块801可用于:在验证操作信息包括用户验证方式标识的情况下,向SDK发送第一通知消息。
第一通知消息包括用户验证方式标识,用于指示SDK通知宿主程序展示与用户验证方式标识匹配的用户验证页面,以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
在一些实施例中,SDK服务器还可包括查询模块。
查询模块可用于根据目标宿主程序标识和预设的第一对应关系,确定与目标宿主程序标识对应的目标用户验证调起方。
第一对应关系包括宿主程序标识与用户验证调起方的关系。
发送模块801可用于在目标用户验证调起方为宿主程序的情况下,向SDK发送第一通知消息。
在一些实施例中,发送模块801还可用于在目标用户验证调起方为SDK的情况下,向SDK发送第四通知消息。
第四通知消息用于指示SDK展示用户验证页面,以提示用户输入第二用户验证输入信息。第二用户验证输入信息用于SDK服务器进行用户验证以得到用户验证结果信息。
在一些实施例中,SDK服务器800还可包括订单标识生成模块。
订单标识生成模块可用于响应于商户系统发送的订单请求消息,生成订单标识。
发送模块801还可用于向商户系统发送订单反馈消息,以使商户系统向SDK发送SDK调用请求消息。
订单反馈消息和SDK调用请求消息包括订单标识。
发送模块801还可用于响应于SDK发送的第一订单查询消息,向SDK发送第一查询反馈消息。
第一查询反馈消息包括与订单标识对应的订单信息。
在一些实施例中,订单请求消息包括指定付款方身份信息。
发送模块801还可用于在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下,向SDK发送支付中止通知消息,以使SDK发出支付提示信息。
在一些实施例中,接收模块802还可用于接收终端设备的SDK发送的第二订单查询消息。
第二订单查询消息包括终端设备扫描收款码得到的第一码信息。
发送模块801还可用于向SDK发送第二查询反馈消息。
第二查询反馈消息包括与第一码信息对应的订单信息。
在一些实施例中,发送模块801还可用于响应于接收的付款码申请消息,向SDK发送付款码反馈消息。
付款码申请消息由SDK发送。付款码反馈消息包括付款码。对应地,支付请求消息由支付受理设备基于扫描的付款码生成。
本申请第五方面提供一种终端设备。终端设备具有SDK和宿主程序。图18为第五方面提供的终端设备的一实施例的结构示意图。如图18 所示,该终端设备900可包括接收模块901、显示模块902和发送模块903。
接收模块901可用于通过SDK获取SDK服务器发送的第一通知消息。
第一通知消息是SDK服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的。安全验证请求消息由SDK服务器响应于接收的支付请求消息发送。
显示模块902可用于响应于第一通知消息,通过SDK通知宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息。
发送模块903可用于通过宿主程序向宿主程序服务器反馈第一用户验证输入信息。
第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
发送模块903还可用于通过SDK向SDK服务器发送通过宿主程序从宿主程序服务器获取的用户验证结果信息,使SDK服务器在用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
在一些实施例中,所述用户验证结果信息还用于使所述SDK服务器在所述用户验证结果信息满足一致性验证条件的情况下,发起所述付款请求。
在一些示例中,一致性验证条件包括:第一用户验证结果信息和第二用户验证结果信息一致。第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给SDK的用户验证结果信息,第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
在本申请实施例中,SDK服务器响应于支付请求消息,向安全控制系统发送安全验证请求消息,以请求安全控制系统对本次支付进行安全验证,以完成SDK所属方所需的安全性方面的验证。在安全验证通过的情况下,终端设备中的SDK接收到SDK服务器发送的用于指示SDK通知宿主程序展示用户验证页面的消息,SDK响应于该消息,触发宿主程序主动 发起用户验证,以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了SDK所属方和宿主程序所属方两个主体的双向验证,提高了支付的安全性,也满足了SDK所属方和宿主程序所属方两个主体对安全性管控的需求。
在一些示例中,SDK具有安全域,SDK中的信息存储于安全域。
SDK与宿主程序之间交互的信息为加密信息。SDK中加、解密的密钥存储于SDK服务器。宿主程序中加、解密的密钥存储于宿主程序服务器。
在一些实施例中,显示模块902还可用于响应于SDK接收的第二通知消息,通过SDK发出拒绝提示信息。
第二通知消息由SDK服务器在验证操作信息包括拒绝支付标识的情况下发送。
显示模块902还可用于响应于SDK接收的第三通知消息,通过SDK发出免密支付提示信息。
第三通知消息由SDK服务器在验证操作信息包括免密支付标识的情况下发送。
其中,用户验证方式反馈消息包括验证操作信息。用户验证方式反馈消息由宿主服务器响应于用户验证方式请求消息发送。用户验证方式请求消息由SDK服务器在安全验证结果信息表征安全验证通过的情况下向宿主程序服务器发送。用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
在一些实施例中,第一通知消息由SDK服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识,用于指示SDK通知宿主程序展示与用户验证方式标识匹配的用户验证页面,以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
在一些实施例中,安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一通知消息由SDK服务器在目标用户验证调起方为宿主程序的情况下发送,目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起 方,目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识,第一对应关系包括宿主程序标识与用户验证调起方的关系。
在一些实施例中,接收模块901还可用于通过SDK获取SDK服务器发送的第四通知消息。第四通知消息由SDK服务器在目标用户验证调起方为SDK的情况下发送。
显示模块902还可用于响应于第四通知消息,调用SDK展示用户验证页面,以提示用户输入第二用户验证输入信息。
发送模块903还可用于通过SDK向SDK服务器反馈第二用户验证输入信息。
第二用户验证输入信息用于SDK服务器进行用户验证以得到用户验证结果信息。
在一些实施例中,接收模块901还可用于通过SDK接收SDK调用请求消息。
SDK调用请求消息由商户系统响应于订单反馈消息生成。订单反馈消息和SDK调用请求消息包括订单标识。订单标识由SDK服务器响应于商户系统发送的订单请求消息生成。
发送模块903还可用于响应于SDK调用请求消息,通过SDK向SDK服务器发送第一订单查询消息。
接收模块901还可用于通过SDK接收SDK服务器响应于第一订单查询消息发送的第一查询反馈消息。
第一查询反馈消息包括与订单标识对应的订单信息。
在一些实施例中,订单请求消息包括指定付款方身份信息。
显示模块902还可用于响应于通过SDK接收的支付中止通知消息,通过SDK发出支付提示信息。
支付中止通知消息由SDK服务器在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下发送。
在一些实施例中,终端设备900还可包括扫描模块。
扫描模块可用于扫描付款码,得到第一码信息;
发送模块903还可用于通过SDK向SDK服务器发送第二订单查询消 息。
第二订单查询消息包括第一码信息。
接收模块901还可用于通过SDK接收SDK服务器发送的第二查询反馈消息。
第二查询反馈消息包括与第一码信息对应的订单信息。
在一些实施例中,发送模块903还可用于通过SDK向SDK服务器发送付款码申请消息。
接收模块901还可用于通过SDK接收SDK服务器发送的付款码反馈消息,付款码反馈消息包括付款码。
显示模块902还可用于显示付款码。
付款码用于被支付受理设备扫描以生成支付请求消息。
本申请第六方面提供一种宿主程序服务器。图19为第六方面提供的宿主程序服务器的一实施例的结构示意图。如图19所示,宿主程序服务器1000可包括接收模块1001、验证模块1002和发送模块1003。
接收模块1001可用于接收终端设备通过宿主程序反馈的第一用户验证输入信息。
终端设备具有软件开发工具包SDK和宿主程序。第一用户验证输入信息在SDK响应于第一通知消息通知宿主程序展示用户验证页面后得到。第一通知消息是SDK服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的。安全验证请求消息由SDK服务器响应于接收的支付请求消息发送。
验证模块1002可用于根据第一用户验证输入信息进行用户验证,得到用户验证结果信息。
发送模块1003可用于向终端设备中的宿主程序发送用户验证结果信息,通过宿主程序将用户验证结果信息传输给SDK,以使SDK向SDK服务器发送用户验证结果信息,在用户验证结果信息表征用户验证通过的情况下,使SDK服务器发起付款请求,以完成支付。
在一些实施例中,发送模块1003还可用于向SDK服务器发送用户验 证结果信息,以使SDK服务器在用户验证结果信息表征用户验证通过且用户验证结果信息满足一致性验证条件的情况下,发起付款请求,以完成支付。
在一些示例中,一致性验证条件包括第一用户验证结果信息和第二用户验证结果信息一致。
第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给SDK的用户验证结果信息。第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
在本申请实施例中,SDK服务器响应于支付请求消息,向安全控制系统发送安全验证请求消息,以请求安全控制系统对本次支付进行安全验证,以完成SDK所属方所需的安全性方面的验证。在安全验证通过的情况下,SDK服务器向终端设备的SDK发送用于指示SDK通知宿主程序展示用户验证页面的消息,以使SDK能够触发宿主程序主动发起用户验证。终端设备可接收用户输入的第一用户验证输入信息,并将第一用户验证输入信息向宿主程序服务器发送,宿主程序服务器可完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了SDK所属方和宿主程序所属方两个主体的双向验证,提高了支付的安全性,也满足了SDK所属方和宿主程序所属方两个主体对安全性管控的需求。
在一些示例中,宿主程序服务器存储有用于对宿主程序与SDK之间交互的信息进行加、解密的密钥。
在一些实施例中,接收模块1001还可用于接收SDK服务器在安全验证结果信息表征安全验证通过的情况下发送的用户验证方式请求消息。
用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
发送模块1003还可用于根据用户验证方式请求消息,向SDK服务器发送用户验证方式反馈消息。
用户验证方式反馈消息包括验证操作信息。
其中,在验证操作信息包括拒绝支付标识的情况下,SDK服务器向SDK发送第二通知消息,第二通知消息用于指示SDK发出拒绝支付提示 信息。在验证操作信息包括免密支付标识的情况下,SDK服务器向SDK发送第三通知消息,第三通知消息用于指示SDK发出免密支付提示信息。
在一些实施例中,第一通知消息由SDK服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识,用于指示SDK通知宿主程序展示与用户验证方式标识匹配的用户验证页面,以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
在一些实施例中,安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。
第一通知消息由SDK服务器在目标用户验证调起方为宿主程序的情况下发送。目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一对应关系包括宿主程序标识与用户验证调起方的关系。
本申请第七方面提供了一种SDK服务器。图20为本申请第七方面提供的SDK服务器的一实施例的结构示意图。如图20所示,SDK服务器1100包括存储器1101、处理器1102及存储在存储器1101上并可在处理器1102上运行的计算机程序。
在一些示例中,上述处理器1102可以包括中央处理器(CPU),或者特定集成电路(Application Specific Integrated Circuit,ASIC),或者可以被配置成实施本申请实施例的一个或多个集成电路。
存储器1101可包括只读存储器(Read-Only Memory,ROM),随机存取存储器(Random Access Memory,RAM),磁盘存储介质设备,光存储介质设备,闪存设备,电气、光学或其他物理/有形的存储器存储设备。因此,通常,存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如,存储器设备),并且当该软件被执行(例如,由一个或多个处理器)时,其可操作来执行参考根据本申请第一方面实施例中的支付方法所描述的操作。
处理器1102通过读取存储器1101中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序,以用于实现上述第一方面的实施例中的支付方法。
在一些示例中,SDK服务器1100还可包括通信接口1103和总线1104。其中,如图20所示,存储器1101、处理器1102、通信接口1103通过总线1104连接并完成相互间的通信。
通信接口1103,主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口1103接入输入设备和/或输出设备。
总线1104包括硬件、软件或两者,将SDK服务器1100的部件彼此耦接在一起。举例来说而非限制,总线1104可包括加速图形端口(Accelerated Graphics Port,AGP)或其他图形总线、增强工业标准架构(Enhanced Industry Standard Architecture,EISA)总线、前端总线(Front Side Bus,FSB)、超传输(HyperTransport,HT)互连、工业标准架构(Industry Standard Architecture,ISA)总线、无限带宽互连、低引脚数(Low pin count,LPC)总线、存储器总线、微信道架构(MicroChannel Architecture,MCA)总线、外围组件互连(Peripheral Component Interconnect,PCI)总线、PCI-Express(PCI-E)总线、串行高级技术附件(Serial Advanced Technology Attachment,SATA)总线、视频电子标准协会局部(Video Electronics Standards Association Local Bus,VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下,总线1104可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线,但本申请考虑任何合适的总线或互连。
本申请第八方面提供了一种终端设备,终端设备可包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。存储器和处理器的种类及关系可参见上述SDK服务器中存储器和处理器的相关说明。与上述SDK服务器的不同之处包括,当存储器中的软件被执行时,其可操作来执行参考根据本申请第二方面实施例中的支付方法所描述的操作;以及,处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序 代码对应的计算机程序,以用于实现上述第二方面的实施例中的支付方法。在一些示例中,终端设备还可包括通信接口和总线。存储器、处理器、通信接口可通过总线连接并完成相互间的通信,存储器、处理器、通信接口和总线之间的通信连接可参见图20所示的SDK服务器中的存储器、处理器、通信接口和总线之间的通信连接,在此不再赘述。
本申请第九方面提供了一种宿主程序服务器,宿主程序服务器可包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。存储器和处理器的种类及关系可参见上述SDK服务器中存储器和处理器的相关说明。与上述SDK服务器的不同之处包括,当存储器中的软件被执行时,其可操作来执行参考根据本申请第三方面实施例中的支付方法所描述的操作;以及,处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序,以用于实现上述第三方面的实施例中的支付方法。在一些示例中,宿主程序服务器还可包括通信接口和总线。存储器、处理器、通信接口可通过总线连接并完成相互间的通信,存储器、处理器、通信接口和总线之间的通信连接可参见图20所示的SDK服务器中的存储器、处理器、通信接口和总线之间的通信连接,在此不再赘述。
本申请第十方面提供一种支付系统,该支付系统可包括上述实施例中的SDK服务器、终端设备和宿主程序服务器,SDK服务器、终端设备和宿主程序服务器的具体内容可参见上述实施例中的相关说明,在此不再赘述。
本申请第十一方面还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序指令,该计算机程序指令被处理器执行时可实现上述实施例中第一方面的支付方法、第二方面的支付方法和/或第三方面的支付方法,且能达到相同的技术效果,为避免重复,这里不再赘述。其中,上述计算机可读存储介质可包括非暂态计算机可读存储介质,如只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等,在此并不限定。
本申请实施例还可提供一种计算机程序产品,该计算机程序产品中的 指令可由SDK服务器、终端设备、宿主程序服务器的处理器执行时,使得SDK服务器、终端设备、宿主程序服务器执行上述第一方面的实施例中的支付方法、第二方面的实施例中的支付方法或第三方面的实施例中的支付方法。
需要明确的是,本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同或相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。对于SDK服务器实施例、终端设备实施例、宿主程序服务器实施例、系统实施例、计算机可读存储介质实施例和计算机程序产品实施例而言,相关之处可以参见方法实施例的说明部分。本申请并不局限于上文所描述并在图中示出的特定步骤和结构。本领域的技术人员可以在领会本申请的精神之后,作出各种改变、修改和添加,或者改变步骤之间的顺序。并且,为了简明起见,这里省略对已知方法技术的详细描述。
上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解,流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器,以产生一种机器,使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解,框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合,也可以由执行指定的功能或动作的专用硬件来实现,或可由专用硬件和计算机指令的组合来实现。
本领域技术人员应能理解,上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合,以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上,应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中,术语“包括”并不排除其他装置或步骤;数量词“一个”不排除多个;术语“第一”、 “第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。
Claims (39)
- 一种支付方法,应用于软件开发工具包SDK服务器,所述方法包括:响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息,所述安全验证请求消息包括安全验证信息,用于指示所述安全控制系统根据所述安全验证信息对所述支付请求消息对应的支付进行安全验证;接收所述安全控制系统发送的安全验证结果信息;在所述安全验证结果信息表征安全验证通过的情况下,向终端设备中的SDK发送第一通知消息,所述终端设备具有SDK和宿主程序,所述第一通知消息用于指示所述SDK通知所述宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息,所述第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息;在所述用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
- 根据权利要求1所述的方法,在所述接收所述安全控制系统发送的安全验证结果信息之后,还包括:在所述安全验证结果信息表征安全验证通过的情况下,向所述宿主程序服务器发送用户验证方式请求消息,所述用户验证方式请求消息包括所述支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上;接收所述宿主程序服务器发送的用户验证方式反馈消息,所述用户验证方式反馈消息包括验证操作信息;在所述验证操作信息包括拒绝支付标识的情况下,向所述SDK发送第二通知消息,所述第二通知消息用于指示所述SDK发出拒绝支付提示信息;在所述验证操作信息包括免密支付标识的情况下,向所述SDK发送第三通知消息,所述第三通知消息用于指示所述SDK发出免密支付提示信息。
- 根据权利要求2所述的方法,其中,所述向终端设备中的SDK发送第一通知消息,包括:在所述验证操作信息包括所述用户验证方式标识的情况下,向所述SDK发送所述第一通知消息,所述第一通知消息包括所述用户验证方式标识,用于指示所述SDK通知所述宿主程序展示与所述用户验证方式标识匹配的用户验证页面,以提示用户输入与所述用户验证方式标识匹配的所述第一用户验证输入信息。
- 根据权利要求1至3中任意一项所述的方法,其中,所述安全验证结果信息包括目标宿主程序标识,所述目标宿主程序标识包括所述支付请求消息对应的支付的宿主程序标识,在所述向终端设备中的SDK发送第一通知消息之前,还包括:根据所述目标宿主程序标识和预设的第一对应关系,确定与所述目标宿主程序标识对应的目标用户验证调起方,所述第一对应关系包括宿主程序标识与用户验证调起方的关系;所述向终端设备中的SDK发送第一通知消息,包括:在所述目标用户验证调起方为所述宿主程序的情况下,向所述SDK发送所述第一通知消息。
- 根据权利要求4所述的方法,在所述根据所述目标宿主程序标识和预设的第一对应关系,确定与所述目标宿主程序标识对应的目标用户验证调起方之后,还包括:在所述目标用户验证调起方为所述SDK的情况下,向所述SDK发送第四通知消息,所述第四通知消息用于指示所述SDK展示用户验证页面,以提示用户输入第二用户验证输入信息,所述第二用户验证输入信息用于所述SDK服务器进行用户验证以得到用户验证结果信息。
- 根据权利要求1所述的方法,其中,所述发起付款请求,包括:在所述用户验证结果信息满足一致性验证条件的情况下,发起所述付款请求。
- 根据权利要求1所述的方法,其中,所述一致性验证条件包括:第一用户验证结果信息和第二用户验证结果信息一致,所述第一用户 验证结果信息为由所述宿主程序服务器通过所述宿主程序传输给所述SDK的所述用户验证结果信息,所述第二用户验证结果信息为从宿主程序服务器获取的所述用户验证结果信息。
- 根据权利要求1所述的方法,其中,所述SDK服务器存储有用于对所述SDK与所述宿主程序之间交互的信息进行加、解密的密钥。
- 根据权利要求1所述的方法,在所述响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息之前,还包括:响应于商户系统发送的订单请求消息,生成订单标识;向所述商户系统发送订单反馈消息,以使所述商户系统向所述SDK发送SDK调用请求消息,所述订单反馈消息和所述SDK调用请求消息包括所述订单标识;响应于所述SDK发送的第一订单查询消息,向所述SDK发送第一查询反馈消息,所述第一查询反馈消息包括与所述订单标识对应的订单信息。
- 根据权利要求9所述的方法,其中,所述订单请求消息包括指定付款方身份信息,所述方法还包括:在所述指定付款方身份信息与所述支付请求消息指示的支付的付款方身份信息不一致的情况下,向所述SDK发送支付中止通知消息,以使所述SDK发出支付提示信息。
- 根据权利要求1所述的方法,在所述响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息之前,还包括:接收所述终端设备的所述SDK发送的第二订单查询消息,所述第二订单查询消息包括所述终端设备扫描收款码得到的第一码信息;向所述SDK发送第二查询反馈消息,所述第二查询反馈消息包括与所述第一码信息对应的订单信息。
- 根据权利要求1所述的方法,在所述响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息之前,还包括:响应于接收的付款码申请消息,向所述SDK发送付款码反馈消息, 所述付款码申请消息由所述SDK发送,所述付款码反馈消息包括付款码;所述支付请求消息由支付受理设备基于扫描的所述付款码生成。
- 一种支付方法,应用于终端设备,所述终端设备具有软件开发工具包SDK和宿主程序,所述方法包括:通过所述SDK获取SDK服务器发送的第一通知消息,所述第一通知消息是所述SDK服务器基于表征安全验证通过的安全验证结果信息发送的,所述安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的,所述安全验证请求消息由所述SDK服务器响应于接收的所述支付请求消息发送;响应于所述第一通知消息,通过所述SDK通知所述宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息;通过所述宿主程序向宿主程序服务器反馈第一用户验证输入信息,所述第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息;通过所述SDK向所述SDK服务器发送通过宿主程序从所述宿主程序服务器获取的所述用户验证结果信息,使所述SDK服务器在所述用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
- 根据权利要求13所述的方法,还包括:响应于所述SDK接收的第二通知消息,通过所述SDK发出拒绝提示信息,所述第二通知消息由所述SDK服务器在所述验证操作信息包括拒绝支付标识的情况下发送;或者,响应于所述SDK接收的第三通知消息,通过所述SDK发出免密支付提示信息,所述第三通知消息由所述SDK服务器在所述验证操作信息包括免密支付标识的情况下发送;其中,用户验证方式反馈消息包括所述验证操作信息,所述用户验证方式反馈消息由所述宿主服务器响应于用户验证方式请求消息发送,所述用户验证方式请求消息由SDK服务器在所述安全验证结果信息表征安全 验证通过的情况下向所述宿主程序服务器发送,所述用户验证方式请求消息包括所述支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
- 根据权利要求14所述的方法,其中,所述第一通知消息由所述SDK服务器在所述验证操作信息包括所述用户验证方式标识的情况下发送,所述第一通知消息包括所述用户验证方式标识,用于指示所述SDK通知所述宿主程序展示与所述用户验证方式标识匹配的用户验证页面,以提示用户输入与所述用户验证方式标识匹配的所述第一用户验证输入信息。
- 根据权利要求13至15中任意一项所述的方法,其中,所述安全验证结果信息包括目标宿主程序标识,所述目标宿主程序标识包括所述支付请求消息对应的支付的宿主程序标识,所述第一通知消息由所述SDK服务器在目标用户验证调起方为所述宿主程序的情况下发送,所述目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方,所述目标宿主程序标识包括所述支付请求消息对应的支付的宿主程序标识,所述第一对应关系包括宿主程序标识与用户验证调起方的关系。
- 根据权利要求16所述的方法,还包括:通过所述SDK获取SDK服务器发送的第四通知消息,所述第四通知消息由所述SDK服务器在所述目标用户验证调起方为所述SDK的情况下发送;响应于所述第四通知消息,调用所述SDK展示用户验证页面,以提示用户输入第二用户验证输入信息;通过所述SDK向所述SDK服务器反馈所述第二用户验证输入信息,所述第二用户验证输入信息用于所述SDK服务器进行用户验证以得到用户验证结果信息。
- 根据权利要求13所述的方法,其中,所述用户验证结果信息还用于使所述SDK服务器在所述用户验证结果信息满足一致性验证条件的情况下,发起所述付款请求。
- 根据权利要求18所述的方法,其中,所述一致性验证条件包括:所述第一用户验证结果信息和第二用户验证结果信息一致,所述第一用户验证结果信息为由所述宿主程序服务器通过所述宿主程序传输给所述SDK的所述用户验证结果信息,所述第二用户验证结果信息为从宿主程序服务器获取的所述用户验证结果信息。
- 根据权利要求13所述的方法,其中,所述SDK具有安全域,所述SDK中的信息存储于所述安全域;所述SDK与所述宿主程序之间交互的信息为加密信息,所述SDK中加、解密的密钥存储于所述SDK服务器,所述宿主程序中加、解密的密钥存储于所述宿主程序服务器。
- 根据权利要求13所述的方法,在所述通过所述SDK获取SDK服务器发送的第一通知消息之前,还包括:通过所述SDK接收SDK调用请求消息,所述SDK调用请求消息由商户系统响应于订单反馈消息生成,所述订单反馈消息和所述SDK调用请求消息包括订单标识,所述订单标识由所述SDK服务器响应于所述商户系统发送的订单请求消息生成;响应于所述SDK调用请求消息,通过所述SDK向所述SDK服务器发送第一订单查询消息;通过所述SDK接收所述SDK服务器响应于所述第一订单查询消息发送的第一查询反馈消息,所述第一查询反馈消息包括与所述订单标识对应的订单信息。
- 根据权利要求21所述的方法,其中,所述订单请求消息包括指定付款方身份信息,所述方法还包括:响应于通过所述SDK接收的支付中止通知消息,通过所述SDK发出支付提示信息,所述支付中止通知消息由所述SDK服务器在所述指定付款方身份信息与所述支付请求消息指示的支付的付款方身份信息不一致的情况下发送。
- 根据权利要求13所述的方法,在所述通过所述SDK获取SDK服务器发送的第一通知消息之前,还包括:扫描付款码,得到第一码信息;通过所述SDK向所述SDK服务器发送第二订单查询消息,所述第二订单查询消息包括所述第一码信息。通过所述SDK接收所述SDK服务器发送的第二查询反馈消息,所述第二查询反馈消息包括与所述第一码信息对应的订单信息。
- 根据权利要求13所述的方法,在所述通过所述SDK获取SDK服务器发送的第一通知消息之前,还包括:通过所述SDK向所述SDK服务器发送付款码申请消息;通过所述SDK接收所述SDK服务器发送的付款码反馈消息,所述付款码反馈消息包括付款码;显示所述付款码,所述付款码用于被支付受理设备扫描以生成所述支付请求消息。
- 一种支付方法,应用于宿主程序服务器,所述方法包括:接收终端设备通过宿主程序反馈的第一用户验证输入信息,所述终端设备具有软件开发工具包SDK和所述宿主程序,所述第一用户验证输入信息在所述SDK响应于第一通知消息通知所述宿主程序展示用户验证页面后得到,所述第一通知消息是所述SDK服务器基于表征安全验证通过的安全验证结果信息发送的,所述安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的,所述安全验证请求消息由所述SDK服务器响应于接收的所述支付请求消息发送;根据所述第一用户验证输入信息进行用户验证,得到用户验证结果信息;向所述终端设备中的所述宿主程序发送所述用户验证结果信息,通过所述宿主程序将所述用户验证结果信息传输给所述SDK,以使所述SDK向所述SDK服务器发送所述用户验证结果信息,在所述用户验证结果信息表征用户验证通过的情况下,使SDK服务器发起付款请求,以完成支 付。
- 根据权利要求25所述的方法,在所述接收终端设备通过宿主程序反馈的第一用户验证输入信息之前,还包括:接收所述SDK服务器在所述安全验证结果信息表征安全验证通过的情况下发送的用户验证方式请求消息,所述用户验证方式请求消息包括所述支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上;根据所述用户验证方式请求消息,向所述SDK服务器发送用户验证方式反馈消息,所述用户验证方式反馈消息包括验证操作信息;其中,在所述验证操作信息包括拒绝支付标识的情况下,所述SDK服务器向所述SDK发送第二通知消息,所述第二通知消息用于指示所述SDK发出拒绝支付提示信息;在所述验证操作信息包括免密支付标识的情况下,所述SDK服务器向所述SDK发送第三通知消息,所述第三通知消息用于指示所述SDK发出免密支付提示信息。
- 根据权利要求26所述的方法,其中,所述第一通知消息由所述SDK服务器在所述验证操作信息包括所述用户验证方式标识的情况下发送,所述第一通知消息包括所述用户验证方式标识,用于指示所述SDK通知所述宿主程序展示与所述用户验证方式标识匹配的用户验证页面,以提示用户输入与所述用户验证方式标识匹配的所述第一用户验证输入信息。
- 根据权利要求25至27中任意一项所述的方法,其中,所述安全验证结果信息包括目标宿主程序标识,所述目标宿主程序标识包括所述支付请求消息对应的支付的宿主程序标识,所述第一通知消息由所述SDK服务器在目标用户验证调起方为所述宿主程序的情况下发送,所述目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方,所述目标宿主程序标识包括所述支付请求消息对应的支付的宿主程序标识,所述第一对应关系包括宿主程序标识与用户验证调起方的关系。
- 根据权利要求25所述的方法,还包括:向所述SDK服务器发送所述用户验证结果信息,以使所述SDK服务器在所述用户验证结果信息表征用户验证通过且所述用户验证结果信息满足一致性验证条件的情况下,发起付款请求,以完成支付。
- 根据权利要求29所述的方法,其中,所述一致性验证条件包括:第一用户验证结果信息和第二用户验证结果信息一致,所述第一用户验证结果信息为由所述宿主程序服务器通过所述宿主程序传输给所述SDK的所述用户验证结果信息,所述第二用户验证结果信息为从宿主程序服务器获取的所述用户验证结果信息。
- 根据权利要求25所述的方法,其中,所述宿主程序服务器存储有用于对所述宿主程序与所述SDK之间交互的信息进行加、解密的密钥。
- 一种软件开发工具包SDK服务器,包括:发送模块,用于响应于接收的支付请求消息,向安全控制系统发送安全验证请求消息,所述安全验证请求消息包括安全验证信息,用于指示所述安全控制系统根据所述安全验证信息对所述支付请求消息对应的支付进行安全验证;接收模块,用于接收所述安全控制系统发送的安全验证结果信息;所述发送模块还用于在所述安全验证结果信息表征安全验证通过的情况下,向终端设备中的SDK发送第一通知消息,所述终端设备具有SDK和宿主程序,所述第一通知消息用于指示所述SDK通知所述宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息,所述第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息;所述发送模块还用于在所述用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
- 一种终端设备,所述终端设备具有软件开发工具包SDK和宿主程序,所述终端设备包括:接收模块,用于通过所述SDK获取SDK服务器发送的第一通知消 息,所述第一通知消息是所述SDK服务器基于表征安全验证通过的安全验证结果信息发送的,所述安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的,所述安全验证请求消息由所述SDK服务器响应于接收的所述支付请求消息发送;显示模块,用于响应于所述第一通知消息,通过所述SDK通知所述宿主程序展示用户验证页面,以提示用户输入第一用户验证输入信息;发送模块,用于通过所述宿主程序向宿主程序服务器反馈第一用户验证输入信息,所述第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息;所述发送模块还用于通过所述SDK向所述SDK服务器发送通过宿主程序从所述宿主程序服务器获取的所述用户验证结果信息,使所述SDK服务器在所述用户验证结果信息表征用户验证通过的情况下,发起付款请求,以完成支付。
- 一种宿主程序服务器,包括:接收模块,用于接收终端设备通过宿主程序反馈的第一用户验证输入信息,所述终端设备具有软件开发工具包SDK和所述宿主程序,所述第一用户验证输入信息在所述SDK响应于第一通知消息通知所述宿主程序展示用户验证页面后得到,所述第一通知消息是所述SDK服务器基于表征安全验证通过的安全验证结果信息发送的,所述安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的,所述安全验证请求消息由所述SDK服务器响应于接收的所述支付请求消息发送;验证模块,用于根据所述第一用户验证输入信息进行用户验证,得到用户验证结果信息;发送模块,用于向所述终端设备中的所述宿主程序发送所述用户验证结果信息,通过所述宿主程序将所述用户验证结果信息传输给所述SDK,以使所述SDK向所述SDK服务器发送所述用户验证结果信息,在所述用户验证结果信息表征用户验证通过的情况下,使SDK服务器发起付款请 求,以完成支付。
- 一种软件开发工具包SDK服务器,包括:处理器以及存储有计算机程序指令的存储器;所述处理器执行所述计算机程序指令时实现如权利要求1至12中任意一项所述的支付方法。
- 一种终端设备,包括:处理器以及存储有计算机程序指令的存储器;所述处理器执行所述计算机程序指令时实现如权利要求13至24中任意一项所述的支付方法。
- 一种宿主程序服务器,包括:处理器以及存储有计算机程序指令的存储器;所述处理器执行所述计算机程序指令时实现如权利要求25至31中任意一项所述的支付方法。
- 一种支付系统,包括如权利要求35所述的软件开发工具包SDK服务器、如权利要求36所述的终端设备和如权利要求37所述的宿主程序服务器。
- 一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序指令,所述计算机程序指令被处理器执行时实现如权利要求1至31中任意一项所述的支付方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210238575.1 | 2022-03-10 | ||
CN202210238575.1A CN114638608A (zh) | 2022-03-10 | 2022-03-10 | 支付方法、终端设备、服务器、系统及介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023168938A1 true WO2023168938A1 (zh) | 2023-09-14 |
Family
ID=81947619
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2022/123922 WO2023168938A1 (zh) | 2022-03-10 | 2022-10-08 | 支付方法、终端设备、服务器、系统及介质 |
Country Status (3)
Country | Link |
---|---|
CN (1) | CN114638608A (zh) |
TW (1) | TW202336668A (zh) |
WO (1) | WO2023168938A1 (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114638608A (zh) * | 2022-03-10 | 2022-06-17 | 中国银联股份有限公司 | 支付方法、终端设备、服务器、系统及介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106304074A (zh) * | 2016-08-31 | 2017-01-04 | 尹子栋 | 面向移动用户的身份验证方法和系统 |
CN106600266A (zh) * | 2016-12-05 | 2017-04-26 | 深圳前海微众银行股份有限公司 | 基于sdk的移动支付方法及装置 |
CN206993151U (zh) * | 2017-07-06 | 2018-02-09 | 北京承启通科技有限公司 | 网络信令安全验证系统 |
US20210012343A1 (en) * | 2019-07-08 | 2021-01-14 | Mastercard International Incorporated | Systems and methods for use in facilitating network interactions |
CN113298523A (zh) * | 2021-05-31 | 2021-08-24 | 中国建设银行股份有限公司 | 运营平台支付方法及金融服务平台 |
WO2021208744A1 (zh) * | 2020-04-15 | 2021-10-21 | 支付宝(杭州)信息技术有限公司 | 应用程序的授权登录 |
CN114638608A (zh) * | 2022-03-10 | 2022-06-17 | 中国银联股份有限公司 | 支付方法、终端设备、服务器、系统及介质 |
-
2022
- 2022-03-10 CN CN202210238575.1A patent/CN114638608A/zh active Pending
- 2022-09-30 TW TW111137387A patent/TW202336668A/zh unknown
- 2022-10-08 WO PCT/CN2022/123922 patent/WO2023168938A1/zh unknown
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106304074A (zh) * | 2016-08-31 | 2017-01-04 | 尹子栋 | 面向移动用户的身份验证方法和系统 |
CN106600266A (zh) * | 2016-12-05 | 2017-04-26 | 深圳前海微众银行股份有限公司 | 基于sdk的移动支付方法及装置 |
CN206993151U (zh) * | 2017-07-06 | 2018-02-09 | 北京承启通科技有限公司 | 网络信令安全验证系统 |
US20210012343A1 (en) * | 2019-07-08 | 2021-01-14 | Mastercard International Incorporated | Systems and methods for use in facilitating network interactions |
WO2021208744A1 (zh) * | 2020-04-15 | 2021-10-21 | 支付宝(杭州)信息技术有限公司 | 应用程序的授权登录 |
CN113298523A (zh) * | 2021-05-31 | 2021-08-24 | 中国建设银行股份有限公司 | 运营平台支付方法及金融服务平台 |
CN114638608A (zh) * | 2022-03-10 | 2022-06-17 | 中国银联股份有限公司 | 支付方法、终端设备、服务器、系统及介质 |
Also Published As
Publication number | Publication date |
---|---|
CN114638608A (zh) | 2022-06-17 |
TW202336668A (zh) | 2023-09-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10614199B2 (en) | Online account access control by mobile device | |
RU2649786C2 (ru) | Мобильное платежное устройство на базе технологии биораспознавания, способ и устройство | |
CN106899552B (zh) | 认证方法,认证终端以及系统 | |
JP6117317B2 (ja) | 否認防止方法、このための決済管理サーバおよび使用者端末 | |
WO2017071208A1 (zh) | 鉴权方法、设备、服务器、系统及存储介质 | |
US12041189B2 (en) | Method for storing and recovering key for blockchain-based system, and device therefor | |
EP2999189A1 (en) | Network authentication method for secure electronic transactions | |
US11088822B2 (en) | Methods, systems, and media for using dynamic public key infrastructure to send and receive encrypted messages | |
WO2015101310A1 (zh) | 一种业务处理方法、装置及系统 | |
JP7457838B2 (ja) | カード管理方法、ユーザ端末、サーバ、システム、及び記憶媒体 | |
CN105512576A (zh) | 一种数据安全存储的方法及电子设备 | |
CN109063450B (zh) | 一种安全存储介质的控制方法、安全存储介质及系统 | |
TWI632798B (zh) | 伺服器、行動終端機、網路實名認證系統及方法 | |
KR102616421B1 (ko) | 생체 인증을 이용한 결제 방법 및 그 전자 장치 | |
CN113836506A (zh) | 身份认证方法、装置、系统、电子设备、存储介质 | |
TW201608499A (zh) | 交易裝置、使用其之交易系統與交易方法 | |
WO2023168938A1 (zh) | 支付方法、终端设备、服务器、系统及介质 | |
WO2024109551A1 (zh) | 数字化支付处理方法、装置、设备、系统及介质 | |
WO2023178924A1 (zh) | 支付方法、用户终端、装置、设备、系统及介质 | |
CN106411520B (zh) | 一种虚拟资源数据的处理方法、装置及系统 | |
CN112966287A (zh) | 获取用户数据的方法、系统、设备和计算机可读介质 | |
US20150310441A1 (en) | Transaction system method, electronic signature tool, and network bank server authentication | |
CN114417309A (zh) | 一种双向身份验证方法、装置、设备及存储介质 | |
CN117350715A (zh) | 支付方法、账户配置方法、系统、装置、设备和介质 | |
TW201826119A (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: 22930562 Country of ref document: EP Kind code of ref document: A1 |