Cross-platform jump payment method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, provides a cross-platform jump payment method and device, electronic equipment and a storage medium, and can be applied to the financial industry. According to the method, when the first use object enters the payment service, the account interface of the at least one bound payment account is presented, manual binding of the use object is not needed, the convenience of account binding operation is improved, and further, when the service platform to which one payment account selected by the use object belongs is jumped to for the first time, the user experience is improved. By presenting the authorized login interface associated with the selected payment account, the user does not need to manually input login information for identity verification, the input operation of first cross-platform jump is reduced, the convenience and response speed of the first cross-platform jump are improved, the service experience of the user is effectively improved, and the user experience is improved. And the retention rate and the competitiveness of the third-party service platform are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology and provides a cross-platform jump payment method, device, electronic device and storage medium. Background Art

[0002] As the business expands, third-party service platforms can, to a certain extent, provide unified bank card management services for different banking systems, and support users to jump from the third-party service platform to the bank system where the bank card has been bound.

[0003] Because each bank system has a different operating system and the object identity information used within each operating system is not shared, different object identifiers are used for the same user between the third-party service platform and different bank systems. As a result, when the third-party service platform first jumps to a bank system, the user is required to manually enter login information (such as name, ID number, card number, mobile phone number, etc.) for identity verification. This means that for users who have multiple bank cards bound to the third-party service platform, repeated identity verification operations are required when the third-party service platform first jumps to the bank system to which different bank cards belong.

[0004] However, when using the above method for cross-platform jump payment, the identity authentication operation is greatly increased in complexity and tediousness, and the operation error rate is significantly increased, thereby seriously reducing the retention rate and competitiveness of the third-party payment platform.

[0005] Therefore, while ensuring information security, how to improve the convenience of the first jump from the third-party service platform to the bank system has become an urgent problem that the third-party service platform needs to solve. Summary of the Invention

[0006] The embodiments of the present application provide a cross-platform jump payment method, device, electronic device and storage medium to improve the convenience of operation during the first cross-platform jump.

[0007] In a first aspect, an embodiment of the present application provides a cross-platform jump payment method, comprising:

[0008] In response to a payment service entry operation triggered by a user, an account interface is presented; the account interface includes: at least one payment account bound by the user on the third-party service platform;

[0009] In response to a selection operation triggered by the user for the at least one payment account, presenting an authorization login interface associated with the selected payment account; the authorization login interface is generated when the user first jumps to the business platform to which the selected payment account belongs;

[0010] In response to the confirmation operation triggered by the user object on the authorization login interface, the system interface of the business platform to which the selected payment account belongs is jumped.

[0011] In a second aspect, an embodiment of the present application provides a cross-platform jump payment device, comprising:

[0012] A first presentation unit is configured to present an account interface in response to a payment service entry operation triggered by a user; the account interface includes at least one payment account bound by the user on the third-party service platform;

[0013] a second presentation unit, in response to a selection operation triggered by the user for the at least one payment account, presenting an authorization login interface associated with the selected payment account; the authorization login interface is generated when the user first jumps to the business platform to which the selected payment account belongs;

[0014] The third presentation unit jumps to the system interface of the business platform to which the selected payment account belongs in response to the confirmation operation triggered by the user on the authorization login interface.

[0015] Optionally, the third presentation unit is specifically configured to:

[0016] In response to the first confirmation operation triggered by the user on the authorization login interface, presenting a notification interface; the notification interface includes an opening method for jumping to the business platform to which the selected payment account belongs;

[0017] In response to the second confirmation operation of the user object on the opening method in the notification interface, jump to the system interface of the business platform to which the selected payment account belongs.

[0018] Optionally, the second presentation unit is specifically configured to:

[0019] In response to a first selection operation triggered by the user on the at least one payment account, presenting a service processing interface associated with the selected payment account; the service processing interface includes: at least one service that the third-party service platform cooperates with the service platform to which the selected payment account belongs;

[0020] In response to the second selection operation triggered by the user for the at least one business, an authorization login interface associated with the selected payment account is presented; the second selection operation is triggered when the user handles a business that requires an external jump for the first time on the third-party service platform.

[0021] Optionally, the third presentation unit is specifically configured to:

[0022] In response to a confirmation operation triggered by the user on the authorized login interface, generating a login credential for the user, and sending the login credential to a business platform to which a selected payment account belongs, so that the business platform sends a request message for obtaining the login information of the user;

[0023] After the request message is verified, the login information of the user object is obtained from the preset object information library based on the login credentials carried in the request message, and the login information is encrypted and sent to the service platform, so that the service platform authenticates the login information;

[0024] After the verification is passed, jump to the system interface of the business platform.

[0025] Optionally, the original signature of the request message is encrypted using a business private key of the business platform, and the third presentation unit is specifically configured to:

[0026] Regenerate a new signature for the request message based on the pre-stored business public key of the business platform;

[0027] The original signature and the new signature are compared, and when the comparison results are the same, it is determined that the request message has passed the verification.

[0028] Optionally, the request message is encrypted using a first key generated by the service platform, and the third presentation unit is specifically configured to:

[0029] Decrypting the first ciphertext of the first key using the service private key to obtain the first key; the first ciphertext is obtained by: the business platform encrypting the first ciphertext using the pre-stored service public key of the third-party service platform;

[0030] The request message is decrypted using the first key to obtain request data for obtaining the login information.

[0031] Optionally, the third presentation unit is specifically configured to:

[0032] Encrypting the login information based on the second key to obtain a response message;

[0033] Encrypting the second key using a pre-stored service public key of the service platform to obtain a second ciphertext of the second key;

[0034] The signature of the response message is encrypted using the service private key, and the encrypted response message is sent to the service platform.

[0035] Optionally, the third presentation unit is further configured to:

[0036] Based on the sent login information, a transmission record is generated between the business platform to which the selected payment account belongs; the transmission record is used to indicate that when the business platform is subsequently jumped to for the second time, the system interface of the business platform is presented.

[0037] Optionally, the device further includes a real-name authentication unit, specifically configured to:

[0038] Performing real-name authentication on the user based on the user's identity information;

[0039] When the real-name authentication is successful, the identity information is encrypted and associated with the object identifier of the user on different business platforms, and stored in the preset object information library.

[0040] Optionally, the second presentation unit is specifically configured to:

[0041] In response to a selection operation triggered by the user for the at least one payment account, querying a transmission record with a business platform to which the selected payment account belongs;

[0042] When the transmission record indicates the first jump to the service platform, querying the binding relationship between the object and the account, the binding relationship includes at least one payment account to which the object is bound;

[0043] When the selected payment account and the usage object satisfy the binding relationship, an authorization login interface associated with the selected payment account is presented.

[0044] Optionally, the device further includes an account binding unit, specifically configured to:

[0045] For the at least one payment account, perform the following operations respectively:

[0046] When the user applies for a payment account and authorizes binding, the user receives the login information of the user sent by the service platform to which the payment account belongs.

[0047] Querying a preset object information database based on the login information to obtain an object identifier of the user object in the business platform to which the payment account belongs;

[0048] Binding the object identifier to the one payment account.

[0049] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of any of the above-mentioned cross-platform jump methods.

[0050] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which includes a computer program. When the computer program is run on an electronic device, the computer program is used to enable the electronic device to execute the steps of any of the above-mentioned cross-platform jump methods.

[0051] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes a computer program, and the computer program is stored in a computer-readable storage medium. The processor of an electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device performs any step of the above-mentioned cross-platform jump method.

[0052] In an embodiment of the present application, as soon as the user enters the payment service, the third-party service platform presents an account interface containing at least one payment account bound to the user on the platform. The user does not need to manually enter information to bind the account, which reduces the account binding process and effectively improves the convenience of the account binding operation. For at least one payment account that has been bound in the account interface, when the user first jumps to the business platform to which a payment account selected by the user belongs, the third-party service platform presents an authorization login interface associated with the selected payment account.

[0053] Furthermore, when the user confirms the authorized login operation, the user does not need to manually enter the login information for identity authentication. The third-party service platform can jump to the system interface of the business platform to which the selected payment account belongs, reducing the input operation during the first cross-platform interface jump, effectively improving the operational convenience and response speed of the first cross-platform interface jump, and thus effectively improving the service experience of the user and increasing the retention rate and competitiveness of the third-party service platform.

[0054] Other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present application. The purposes and other advantages of the present application can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0056] Figure 1 A schematic diagram of an application scenario provided in an embodiment of the present application;

[0057] Figure 2 A flowchart of a real-name authentication method provided in an embodiment of the present application;

[0058] Figure 3 A schematic diagram of a cross-platform payment method provided in an embodiment of the present application;

[0059] Figure 4A A schematic diagram of the payment account binding process provided in an embodiment of the present application;

[0060] Figure 4B A schematic diagram of the binding terms prompt interface provided in an embodiment of the present application;

[0061] Figure 4C A schematic diagram of the encrypted information transmission process during account binding provided in an embodiment of the present application;

[0062] Figure 4D A schematic diagram of the interactive process for binding a payment account provided in an embodiment of the present application;

[0063] Figure 5A A schematic diagram of an account interface of a credit card payment account provided in an embodiment of the present application;

[0064] Figure 5B A schematic diagram of an account interface for a payment account of a savings card provided in an embodiment of the present application;

[0065] Figure 6A A schematic diagram of a method for presenting an authorization login interface provided in an embodiment of the present application;

[0066] Figure 6B A flowchart of presenting an authorization login interface provided in an embodiment of the present application;

[0067] Figure 6C A schematic diagram of another method of presenting an authorization login interface provided in an embodiment of the present application;

[0068] Figure 7A A schematic diagram of a cross-platform jump interface provided in an embodiment of the present application;

[0069] Figure 7B A schematic diagram of the process of jumping to the system interface provided in an embodiment of the present application;

[0070] Figure 7C A schematic diagram of a cross-platform jump method provided in an embodiment of the present application;

[0071] Figure 7D A schematic diagram of another cross-platform jump method provided in an embodiment of the present application;

[0072] Figure 7E A schematic diagram of the manual input interface jump provided in an embodiment of the present application;

[0073] Figure 8A schematic diagram of the backend implementation process of cross-platform jump provided in an embodiment of the present application;

[0074] Figure 9A A schematic diagram of a non-first jump interface provided in an embodiment of the present application;

[0075] Figure 9B A schematic diagram of another interface for non-first jump provided in an embodiment of the present application;

[0076] Figure 10 A schematic diagram of the interactive process of cross-platform jump provided in an embodiment of the present application;

[0077] Figure 11 A schematic diagram of the information encryption transmission process during cross-platform jump provided in an embodiment of the present application;

[0078] Figure 12 A schematic diagram of the structure of a cross-platform jump device provided in an embodiment of the present application;

[0079] Figure 13 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0080] Figure 14 A schematic diagram of the structure of a terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0081] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other in any way. In addition, although a logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.

[0082] For ease of understanding, the terms involved in the embodiments of this application are explained below.

[0083] Login information: refers to key information used for identity verification and login, such as name, ID number, bank card number, mobile phone number, etc. This information is usually used for identity verification and risk control on banking platforms and third-party service platforms.

[0084] Real-name authentication: refers to the process of confirming the identity of the user by combining the identity information provided by the user (such as name, ID number, mobile phone number, etc.) with biometric features (such as face, fingerprint, etc.). It can ensure the authenticity of the user's identity and help prevent identity impersonation and fraud.

[0085] Token: A unique identifier used to verify the identity of an object. It is generated by the backend server and assigned to the frontend client. The frontend client can query the backend server for information related to the object based on the Token.

[0086] National Cryptography Standards: Refers to the commercial cryptographic algorithm standards published by the State Cryptography Administration, including SM1, SM2, SM3, SM4, etc. This application uses National Cryptography Standards algorithms, which comply with national information security policies and regulatory requirements.

[0087] SM2 algorithm: elliptic curve public key cryptography algorithm published by the State Cryptography Administration, mainly used for digital signatures and public key encryption.

[0088] SM4 algorithm: A symmetric encryption algorithm published by the State Cryptography Administration, mainly used for symmetric encryption of data.

[0089] Dedicated line: refers to a dedicated communication line used for data transmission between two systems. It has the characteristics of exclusivity, high bandwidth, and high reliability, and is used to improve the security and stability of data transmission.

[0090] Open API protocol: refers to a public, standardized application program interface protocol that defines the data exchange format, communication protocol, security mechanism, etc. between the platform and the caller.

[0091] Universally Unique Identifier (UUID): A standard that typically consists of 32 hexadecimal characters (128 bits) used to uniquely identify information in a computer system. The purpose is to ensure that identifiers generated in a distributed system are globally unique, even if generated by different computers.

[0092] The following is a brief introduction to the design concept of the embodiments of this application.

[0093] At present, third-party service platforms can provide unified management of different bank cards to a certain extent. For certain specific business scenarios, due to compliance requirements or technical limitations, users need to enter the system interface of the platform to which the bank card belongs to complete specific business operations. Therefore, jumping to the system interface of the platform to which the bound bank card belongs is the basic operating procedure of the third-party service platform.

[0094] To ensure the financial security of users, related technologies require users to manually enter their login information for authentication when first redirected to the system interface of the bank card platform. For users with multiple bank cards, the repeated login process of each redirect to a different bank card platform is particularly cumbersome, reducing user efficiency and potentially leading to user boredom after repeated input, resulting in reduced use of third-party service platforms. Furthermore, frequent manual input increases the risk of user input errors, potentially leading to transaction failures or other unnecessary inconvenience.

[0095] In view of this, a cross-platform jump payment method is provided in an embodiment of the present application. When the user enters the payment service, the third-party service platform presents an account interface containing at least one payment account bound to the user on the platform. The user does not need to manually enter information for account binding, which reduces the account binding process and effectively improves the convenience of the account binding operation; for at least one payment account bound in the account interface, when jumping to the business platform to which a payment account selected by the user belongs for the first time, the third-party service platform presents an authorization login interface associated with the selected payment account. Furthermore, when the user confirms the authorized login operation, the user does not need to manually enter login information for identity authentication and login, and the third-party service platform can jump to the system interface of the business platform to which the selected payment account belongs, reducing the input operation when jumping payment across the first platform interface, effectively improving the convenience and response speed of the first cross-platform interface jump payment, thereby effectively improving the service experience of the user and increasing the retention rate and competitiveness of the third-party service platform.

[0096] It is understandable that in the specific implementation of this application, the login information and identity information involved, when applied to the methods or products of the following embodiments of this application, need to obtain the permission or consent of the user, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0097] The following briefly introduces the application scenarios to which the technical solutions of the embodiments of the present application can be applied. It should be noted that the application scenarios described below are only used to illustrate the embodiments of the present application and are not limiting. In the specific implementation process, the technical solutions provided by the embodiments of the present application can be flexibly applied according to actual needs.

[0098] See Figure 1 As shown, it is a schematic diagram of an application scenario provided by an embodiment of the present application. In this scenario, a third-party service platform 100 and a business platform 200 may be included.

[0099] In one embodiment, the third-party service platform 100 includes a front-end client 101 and a back-end server 102. The front-end client 101 is used to interact with users, including but not limited to software clients with payment functions, browsers, etc. The back-end server 102 is used to interact with the business platform 200 to respond to operations received by the front-end client 101. The business platform 200 also includes the front-end client 201 and the back-end server 202. The front-end client 201 is used to interact with users, including but not limited to bank card payment account application services, loan and repayment services, balance inquiry services, transfer and repayment services, etc. The back-end server 202 is used to interact with the third-party service platform 100 to provide login information associated with the user's payment account and return the user's identity authentication login results.

[0100] In one embodiment, the front-end client 101 and the front-end client 102 can be installed on a terminal device, which includes but is not limited to a smart phone, a smart TV, a laptop computer, a desktop computer, a vehicle-mounted terminal, etc. The back-end server 102 and the back-end service 202 can be independent physical servers, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, but are not limited to these.

[0101] In one embodiment, the third-party service platform may further configure a database, which may be used to store login information associated with objects, transmission records of login information, binding relationships between objects and accounts, and the like.

[0102] In one embodiment, the cross-platform jump payment method can be executed by the third-party service platform 100, and the business platform 200 may participate in the execution process. For example, when a user applies for a bank card on the business platform 200, if the user agrees to bind the bank card to the third-party service platform 100, the business platform 200 sends the login information associated with the payment account of the bank card to the third-party service platform 100 through the binding interface. In this way, when the user enters the service provided by the third-party service platform 200, an account interface including at least one payment account bound to the user can be presented. Furthermore, when the user confirms the authorization to log in to a selected payment account for the first time, the third-party service platform 100 sends the user's login information to the business platform 200 through the information query interface for identity authentication and login. If the verification is successful, the third-party service platform 100 jumps to the system interface of the business platform to which the selected payment account belongs.

[0103] The third-party service platform 100 and the business platform 200 can be directly or indirectly connected to each other through one or more networks. The network can be a wired network or a wireless network. For example, the wireless network can be a mobile cellular network, a Wireless Fidelity (WIFI) network, or a dedicated line. This embodiment of the present application does not limit this.

[0104] In one possible application scenario, the relevant data involved in the embodiments of this application (such as login information, etc.) can be stored using cloud storage technology. Cloud storage is a new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of different types of storage devices (or storage nodes) in the network through application software or application interfaces to work together and provide external data storage and service access functions.

[0105] Of course, the method provided in the embodiment of the present application is not limited to Figure 1 The application scenarios shown can also be used in other possible application scenarios, and the embodiments of this application are not limited thereto. Figure 1 The functions that can be implemented by each device in the application scenario shown will be described in subsequent method embodiments and will not be described in detail here.

[0106] Third-party service platforms are dedicated to enabling users to conveniently manage multiple bank cards belonging to different business platforms through a single platform. Through collaboration with different business platforms, they offer features such as bill inquiries, expedited repayments, and scheduled reminders. To protect user privacy, the object groups owned by different business platforms within the third-party service platform are isolated. This means that the same user will have different object identifiers across different business platforms.

[0107] Taking WeChat as an example of a third-party service platform, users can follow the official accounts of the banking systems to which multiple bank cards belong on WeChat, and set different object identifiers for the same WeChat account in different official accounts.

[0108] Optionally, the object identifier may be an object ID consisting of at least one of numbers, characters, and symbols.

[0109] To ensure the authenticity and validity of the user's identity, the third-party service platform usually performs real-name authentication on the user based on the user's identity information. After the real-name authentication is successful, the identity information is encrypted and stored in correspondence with the user's object identifier on different business platforms. A preset identity information table is generated for input-free login during subsequent cross-platform jump payment.

[0110] See Figure 2 As shown in FIG, a flow chart of a real-name authentication method provided in an embodiment of the present application is applied to a third-party service platform. The specific process is as follows:

[0111] S1: The payment service sends a verification code acquisition request in response to the identity information input operation triggered by the usage object.

[0112] The user enters their name, ID number, mobile phone number, email address, and other personal information on the third-party service's real-name authentication interface and submits a real-name authentication request. The payment service responds to the request by sending a verification code request based on the mobile phone number or email address provided in the identity information.

[0113] S2: The verification service generates a verification code for this input and returns it to the user.

[0114] The verification code may be a text message verification code or an email verification code, including but not limited to numbers, letters, or a combination of the two.

[0115] S3: The payment service verifies the verification code in response to the verification code input operation triggered by the usage object.

[0116] The verification content includes but is not limited to the timeliness and accuracy of the verification code, the validity and ownership of the mobile phone number, etc.

[0117] S4: When the verification code is correct, the payment service encrypts the identity information of the user and sends it to the authentication API to obtain the authentication result.

[0118] The payment service will use the identity information submitted by the user, such as name and ID number, to call the identity authentication API to verify the authenticity of the user's identity through encryption and dedicated line transmission.

[0119] S5: When the identity information matches, the payment service collects the face image of the user through the camera and encrypts and transmits it to the face recognition service.

[0120] To prevent identity fraud, the payment service guides the user to perform facial recognition, uses a camera to collect the user's facial image, and sends it to the facial recognition service through encryption and dedicated line transmission.

[0121] S6: The face recognition service sends the face image to the authentication API for face comparison and returns the face comparison result to the payment service.

[0122] By comparing the collected face image with the image in the face database, it is ensured that the operation is performed by the user himself.

[0123] S7: When the face comparison is successful, the payment service prompts the user that the real-name authentication is successful and updates the user's authentication status.

[0124] When the real-name authentication of the user object succeeds, the authentication status is marked as authenticated.

[0125] S8: The payment service sends the identity information of the user to the key system for encryption, and receives the encrypted identity information.

[0126] Payment services can use the SM4 algorithm to encrypt the user's name, ID number, mobile phone number and other identity information, and transmit it through a dedicated line. In this way, even if the database is attacked, the user's personal information cannot be cracked due to encryption.

[0127] S9: The payment service associates the encrypted identity information with the object identifiers of the user under different business platforms, and stores the information in a preset identity information table.

[0128] Table 1 shows the contents of the preset identity information table.

[0129] Table 1. Identity information table

[0130]

[0131] S10: When the face comparison fails, the payment service prompts that the user's real-name authentication fails.

[0132] S11: When the identity information does not match, the payment service prompts that the user's real-name authentication has failed.

[0133] S12: When the verification code is incorrect, the payment service prompts that the user's real-name authentication has failed.

[0134] If any of the face, identity information, and verification code verification fails, real-name authentication will fail. At this time, the payment service will prompt the user to re-authenticate or contact customer service.

[0135] The third-party service platform uses real-name authentication to ensure that the identity of the user is authentic and valid. In this way, after the real-name authentication is successful, the identity information submitted by the user during the real-name authentication process is associated with the object identifier of the user under different business platforms and stored in a preset identity information table, so that there is no need to enter the login when jumping to payment across platforms in the future, thereby improving the convenience and efficiency of the login operation.

[0136] It should be noted that the embodiment of the present application does not impose any restrictive requirements on the timing of real-name authentication. Real-name authentication can be performed when the user registers an account on a third-party service platform, or when the user uses the payment service provided by the third-party service platform.

[0137] See Figure 3 , which is a flow chart of a cross-platform jump payment method provided in an embodiment of the present application. The method is applied to a third-party service platform, and the specific process is as follows:

[0138] S301: The third-party service platform presents an account interface in response to a payment service entry operation triggered by a usage object.

[0139] The account interface includes at least one payment account bound to the user on the third-party service platform. Figure 4A , is a schematic diagram of the binding process for each payment account, which mainly includes the following steps:

[0140] S300_1: When a user applies for a payment account and authorizes binding, the third-party service platform receives the user's login information sent by the business platform to which the payment account belongs.

[0141] When the user successfully applies for a bank card on the business platform, the front-end client of the business platform presents a successful card activation interface, which includes terms for binding to a third-party service platform. When the user ticks the box to agree to bind the payment account of the bank card to the third-party service platform, the back-end server of the business platform calls the account binding interface developed by the third-party service platform, and sends the login information submitted by the user when applying for the bank card to the third-party service platform. The third-party service platform returns a receipt response of the login information through the account binding interface.

[0142] like Figure 4B The figure shows a diagram of the successful card opening interface, which includes the terms for binding the payment account of the bank card to the third-party service platform.

[0143] In one embodiment, the account binding interface is developed based on an open API protocol, which specifies request parameters that the third-party service platform obtains from the business platform, as shown in Table 2, and return parameters that the third-party service platform sends to the business platform, as shown in Table 3.

[0144] Table 2. Request parameters for the account binding interface

[0145] Parameter name type Is this field required? Parameter Description certType String yes Document type certId String yes ID number name String yes Name mobile String yes Phone number cardId String String Bank card number

[0146] Table 3. Return parameters of the account binding interface

[0147] Parameter name type Is this field required? Parameter Description retCode String yes Response Code retMsg String yes Response information

[0148] In one embodiment, to ensure the security of the login information transmission, the backend server of the business platform may encrypt the login information and transmit it to the third-party service platform via a dedicated line.

[0149] In one embodiment, when the login information is transmitted through the account binding interface, a mixed encryption of multiple encryption algorithms in the open API protocol can be used to further improve the security of the login information transmission.

[0150] For example, SM2 algorithm and SM4 algorithm are used for hybrid encryption.

[0151] In one embodiment, when the third-party service platform and the business platform develop an account binding interface, they can each generate a public-private key pair for signature verification and exchange and store them. That is, the third-party service platform stores the public-private key pair for signature verification generated by the business platform, and at the same time, the business platform also stores the public-private key pair for signature verification generated by the third-party service platform.

[0152] Among them, the public-private key pair generated by the business platform for signature verification is recorded as the business public-private key pair, which includes a business private key and a business public key; the public-private key pair generated by the third-party service platform for signature verification is recorded as the service public-private key pair, which includes a service private key and a service public key.

[0153] See also Figure 4C , a schematic diagram of the encrypted transmission process of login information through the account binding interface, the specific process is as follows:

[0154] S1: The business platform uses the third key to encrypt the login information submitted when applying for a bank card and obtains an account binding message.

[0155] Optionally, the third key is a key randomly generated by the service platform using the SM4 algorithm.

[0156] S2: The business platform uses the pre-stored service public key of the third-party service platform to encrypt the third key and generate a third ciphertext of the third key.

[0157] Optionally, the service public key of the third-party service platform is a public key generated using the SM2 algorithm.

[0158] S3: The business platform uses its own business private key to encrypt the signature of the account binding message.

[0159] Optionally, the business public key of the business platform is a public key generated using the SM2 algorithm.

[0160] S4: The business platform sends the mixed encrypted account binding message to the third-party service platform.

[0161] S5: The third-party service platform uses the pre-stored public key of the business platform to verify the signature of the account binding message.

[0162] By verifying the signature, data is prevented from being tampered with, ensuring that the login information received by the third-party service platform is exactly the same as the login information sent by the business platform.

[0163] S6: After the signature verification is passed, the third-party service platform uses its own service private key to decrypt the third ciphertext to obtain the third key.

[0164] Optionally, the service private key of the third-party service platform is a public key generated using the SM2 algorithm.

[0165] S7: The third-party service platform uses the third key to decrypt the account binding message and obtain the login information of the payment account corresponding to the applied bank card.

[0166] After users complete real-name authentication on a third-party service platform, they can automatically bind their bank card payment account to the platform through an account binding interface developed using a unified open API protocol. This reduces the number of manual card binding steps required by users, improving user convenience and reducing the risk of errors in manual card binding, thereby strengthening users' trust in the platform. Furthermore, the automated card binding process improves the overall efficiency of the third-party service platform, reducing user time spent on the platform and effectively increasing user satisfaction and retention. Furthermore, the adoption of an open API protocol ensures compatibility and interoperability with different business platforms. This not only reduces the complexity of system integration but also enhances the scalability and maintainability of the third-party service platform, making it easier for third-party service platforms to collaborate with multiple business platforms, increasing the volume and comprehensiveness of card binding, thereby attracting more users, expanding their customer base, and improving their market competitiveness. Furthermore, the open API protocol helps third-party service platforms quickly respond to market changes and launch new features and services, further strengthening their market position and customer loyalty, laying a solid foundation for their long-term development.

[0167] S300_2: The third-party service platform queries a preset object information database based on the login information, and obtains the object identifier of the usage object in the business platform to which the payment account belongs.

[0168] Among them, the object information library contains the identity information of each user object (i.e., the identity information table), as well as the binding relationship between the object and the account. The binding relationship includes at least one payment account that each user object has been bound to on the third-party service platform. The binding relationship can be stored through the card binding table.

[0169] In one embodiment, the third-party service platform generates different object identifiers for the same user under different business platforms. The object identifier for each business platform user is unique. The login information adds the bank card number to the identity information stored in the identity information table. Therefore, the login information can be used to query the identity information table for the object identifier generated for the user under the business platform to which the payment account belongs. The contents of the identity information table are shown in Table 1 and are not further described here.

[0170] S300_3: The third-party service platform binds the queried object identifier with the payment account.

[0171] The third-party service platform can maintain a card binding table in the database. After obtaining the object identifier of the user in the business platform to which the applied bank card belongs, it queries the card binding table. When the object identifier in the card binding table is not associated with the payment account of the bank card, the object identifier is bound to the payment account of the bank card and stored in the card binding table.

[0172] Table 4 shows the contents of the card binding table.

[0173] Table 4, Card Binding Table

[0174]

[0175]

[0176] See also Figure 4D , a flowchart of binding a payment account on a third-party service platform. The specific process is as follows:

[0177] S1: The business platform responds to the bank card application operation triggered by the user and applies for a bank card for the user.

[0178] Among them, when the bank card is a credit card, the business platform will review the economic situation of the user and apply for a credit card for the user after the review is passed.

[0179] S2: After successful processing, the business platform presents a card activation success interface containing the terms and conditions binding to the third-party service platform.

[0180] Among them, the card opening success interface is as follows Figure 4B shown.

[0181] S3: In response to the user's triggering of a check operation on the binding terms, the business platform encrypts the login information submitted by the user when applying for a bank card.

[0182] The encryption process of the login information is as described in the above embodiment and will not be described again here.

[0183] S4: The business platform calls the account binding interface and sends the encrypted login information to the third-party service platform.

[0184] Optionally, in order to ensure the security of the transmission of login information, the login information can be transmitted using a dedicated line between the business platform and the third-party service platform.

[0185] S5: The third-party service platform queries a preset object information database based on the login information, and obtains an object identifier generated for the user object of the business platform to which the bank card belongs.

[0186] Specifically, the third-party service platform can query the preset object information database based on the identity information such as name, ID number, etc. in the login information.

[0187] S6: The third-party service platform queries the card binding table to obtain the account binding result corresponding to the object identifier.

[0188] The card binding table includes at least one payment account bound to each user on the third-party service platform.

[0189] S7: When the object identifier is not bound to the payment account of the bank card, the third-party service platform binds the object identifier to the payment account and returns a successful binding result through the account binding interface.

[0190] S8: When the object identifier is bound to the payment account of the bank card, the third-party service platform returns a successful binding result through the account binding interface.

[0191] In an embodiment of the present application, through an account binding interface developed based on an open API protocol, the business platform supports automatically sending the login information submitted by the user when applying for a bank card to a third-party service platform when the user applies for a bank card and authorizes the binding, thereby collecting the user's payment account from the source of the bank card. In this way, as soon as the user enters the payment service of the third-party service platform, the third-party service platform can present the payment account of at least one bound bank card, without the need for the user to manually enter the bank card number and other information for binding, thereby improving the convenience of card binding.

[0192] After the user has bound at least one payment account on the third-party service platform, the user clicks on the payment service icon through the front-end client of the third-party service platform to enter the payment service provided by the third-party payment platform. The back-end server of the third-party service platform responds to the entry operation of the payment service, initializes the account interface of the payment service, and presents the account interface to the user through the front-end client.

[0193] Optionally, the payment service may be a credit card lending service or a savings card consumption service, and different payment services may have different entry points.

[0194] Take the example of a credit card loan service where the payment service is provided. Figure 5A As shown, the user clicks on the loan service on the front-end client of the third-party service platform, and the back-end service of the third-party service platform loads the payment account corresponding to at least one bound credit card, and presents an account interface containing at least one payment account through the front-end client.

[0195] Take the consumption service of savings card as an example, Figure 5B As shown, the user clicks "Wallet" on the front-end client of the third-party service platform, and clicks on the bank card service on the wallet interface. The back-end service of the third-party service platform loads the payment account corresponding to at least one bound savings card, and presents an account interface containing at least one payment account through the front-end client.

[0196] As soon as the user enters the payment service, the third-party service platform will present an account interface containing at least one payment account bound by the user on the platform. The user does not need to manually enter information to bind the account, which reduces the account binding process and effectively improves the convenience of the account binding operation.

[0197] S302: The third-party service platform presents an authorization login interface associated with the selected payment account in response to a selection operation triggered by the user for at least one payment account.

[0198] The authorization login interface is generated when you first jump to the business platform to which a selected payment account belongs, and includes prompt information for entering the login information for the business platform.

[0199] In one embodiment, when the third-party service platform has not yet established a cooperative business with the business platform, when the user first enters the account interface from the third-party service platform and selects a business platform to which a payment account belongs, the background service of the third-party service platform responds to the user's selection operation, initializes the authorization login interface associated with the selected payment account, and presents the authorization login interface to the user through the foreground client.

[0200] like Figure 6A As shown, since the third-party service platform and the XX business platform have not yet established a cooperative business, all transactions under the XX business platform must be processed through the official service system interface. In this case, when the user first selects payment account 1 ("XX business platform, credit card number **908") on the account interface, the third-party service platform's front-end client presents the XX business platform's login authorization interface, allowing users to log in to the platform without inputting any information.

[0201] With the deepening cooperation between third-party service platforms and business platforms, users can handle some simple businesses on the third-party service platform, while for some special businesses (such as checking credit limits, checking details, borrowing and repaying, etc.), they need to jump to the business platform for the first time.

[0202] In one embodiment, the presentation process of the authorization login interface is as follows: Figure 6B As shown, it mainly includes the following steps:

[0203] S3021: In response to a first selection operation triggered by a user object on at least one payment account, a business processing interface associated with the selected payment account is presented.

[0204] The business processing interface includes at least one business that is jointly conducted between the third-party service platform and the business platform to which the selected payment account belongs.

[0205] like Figure 6C As shown, when the user selects payment account 1 of "XX business platform, credit card number is **908" in the account interface, the background server of the third-party service platform initializes the business processing interface of at least one business (such as: checking details, redeeming points, checking credit limit, receiving discounts, repayment records, card settings, etc.) that cooperates with the XX business platform, and presents the business processing interface to the user through the front-end client.

[0206] S3022: In response to a second selection operation triggered by the object for at least one business, presenting an authorization login interface associated with a selected payment account.

[0207] The second selection operation is triggered when the user handles a business requiring external jump for the first time on the third-party service platform.

[0208] Assume that Figure 6C In the business processing interface, the "check credit limit" service needs to be processed externally on the XX business platform. When the user applies for the "check credit limit" service for the payment account 1 with the credit card number **908 under the "XX business platform" for the first time, the backend server of the third-party service platform initializes the input-free login authorization login interface of the XX business platform and presents the authorization login interface through the front-end client.

[0209] For a selected payment account, when the user jumps from outside the third-party service platform to the business platform to which the payment account belongs for the first time to handle specific business, the third-party service platform will present an authorization login interface that does not require input, thereby avoiding manual input operations when jumping across cross-platform payment interfaces and improving the convenience of cross-platform jump operations.

[0210] In one embodiment, during the process of presenting the authorization login interface, the third-party service platform may check the binding relationship between a selected payment account and the user object.

[0211] In specific implementation, the third-party service platform responds to the selection operation triggered by the user for at least one payment account, queries the transmission record of the business platform to which the selected payment account belongs, and when the transmission record indicates the first jump to the business platform, queries the binding relationship between the object and the account, wherein the binding relationship includes at least one payment account that the user has bound to the third-party payment platform. When the selected payment account satisfies the binding relationship with the user, it indicates that the selected payment account is the payment account of the bank card applied for by the user himself, and therefore the authorization login interface associated with the selected payment account can be presented.

[0212] Optionally, the binding relationship between the object and the account is as shown in Table 4, and each usage object is bound to at least one payment account on the third-party service platform.

[0213] In one embodiment, when a selected payment account does not satisfy a binding relationship with the user object, it indicates that the selected payment account is not the payment account of the bank card applied for by the user object himself. Therefore, an input login interface associated with the selected payment account can be presented to support the user object to enter the bank card number in the input login interface for original login operation.

[0214] In an embodiment of the present application, by storing the binding relationship between the object and the account, it is checked whether a selected payment account is the payment account of the object's own bank card, thereby avoiding non-personal operations and improving the security of cross-platform jumps.

[0215] S303: The third-party service platform responds to the confirmation operation triggered by the user on the authorization login interface and jumps to the system interface of the business platform to which the selected payment account belongs.

[0216] In the case of jumping to the business platform to which a selected payment account belongs for the first time, when the user confirms the input-free login in the presented authorization login interface, the third-party service platform directly jumps to the system interface of the business platform to which the selected payment account belongs.

[0217] The system interface may be the homepage of an official service of a business platform to which a selected payment account belongs.

[0218] like Figure 7A As shown, the user selects payment account 1 of "credit card number **908 under XX business platform" for the first time. When the user clicks "Agree to authorization and proceed" in the authorization login interface, the front-end client of the third-party service platform presents the home page of the XX business platform.

[0219] In one embodiment, in order to avoid mistaken cross-platform jumps, before jumping to the system interface of the business platform to which a selected payment account belongs, the user may be asked to confirm whether to enter the business platform.

[0220] See also Figure 7B , which is the process of jumping to the system interface of the business platform to which the selected payment account belongs, mainly includes the following steps:

[0221] S3031: In response to a first confirmation operation triggered by the object on the authorization login interface, presenting a notification interface.

[0222] The notification interface includes a method for jumping to the business platform to which a selected payment account belongs.

[0223] Optionally, the method of jumping to the business platform to which the selected payment account belongs includes but is not limited to: opening a mini program, opening a software APP, etc.

[0224] For example, Figure 7C As shown, the user performs the "limit check" service for the first time for the payment account 1 of "XX business platform, credit card number is **908". When the user clicks "Agree to authorization and proceed" in the authorization login interface, the front-end client of the third-party service platform presents a notification interface of "The "XX business platform" applet is about to be opened".

[0225] For example, Figure 7D As shown, the user performs the "limit check" service for the first time for the payment account 1 of "XX business platform, credit card number is **908". When the user clicks "Agree to authorization and proceed" in the authorization login interface, the front-end client of the third-party service platform presents a notification interface of "The "XX business platform" APP is about to be opened".

[0226] S3032: In response to the user object's second confirmation operation on the opening method in the notification interface, jump to the system interface of the business platform to which the selected payment account belongs.

[0227] The system interface may be a business interface of a specific business included in a business platform to which a selected payment account belongs.

[0228] exist Figure 7C In the notification interface, when the user clicks "Allow" in the notification interface, the third-party service platform jumps to the XX business platform through the applet of "XX business platform" and presents the business interface of the "check credit limit" service.

[0229] exist Figure 7D In the notification interface, when the user clicks "Allow" in the notification interface, the third-party service platform jumps to the XX business platform through the "XX business platform" APP to enter the business interface of the "Check Credit Limit" service.

[0230] For a payment account selected by the user, a notification interface containing the opening method of jumping to the business platform to which the payment account belongs is presented, thereby avoiding input-free cross-platform jumps triggered by accidental operations and improving the user's trust.

[0231] In one embodiment, when the user refuses the input-free authorization login, the front-end client of the third-party service platform can present an input login interface to support the user to enter the bank card number in the input login interface for the original login operation.

[0232] For example, Figure 7E As shown, when the user clicks "Do not authorize yet and proceed" in the authorization login interface, the third-party service platform presents a login interface for inputting the credit card number of payment account 1.

[0233] In one embodiment, when jumping across cross-platform payment interfaces, in order to reduce the development costs of compatibility and interoperability with different business platforms, the third-party service platform may develop an information query interface based on an open API protocol for the business platform interface, thereby interacting with the business platform to which a selected payment account belongs.

[0234] See also Figure 8 , which is a schematic diagram of the interactive process when jumping across platforms, mainly includes the following steps:

[0235] S303_1: In response to the confirmation operation triggered by the user on the authorization login interface, generate the user's login credentials, and send the login credentials to the business platform to which the selected payment account belongs, so that the business platform sends a request message for obtaining the user's login information.

[0236] After the user clicks "Agree to Authorization and Proceed" on the authorization login interface, the front-end client of the third-party service platform sends a jump request for authorization login without input to the back-end server of the third-party service platform. The back-end server generates a unique login credential for the user based on the jump request.

[0237] In one embodiment, when a third-party service platform collaborates with different business platforms, it generates unique object identifiers for each user on each of these platforms. Therefore, for the currently logged-in user, the third-party service platform's backend server generates login credentials for the user based on the user's object identifier on the business platform to which the selected payment account belongs, combined with the timestamp and UUID.

[0238] After the third-party service platform generates the login credentials for the user, it sends the login credentials to the front-end client of the business platform to which the selected payment account belongs. The front-end client of the business platform forwards the login credentials to the back-end server of the business platform. The back-end server of the business platform accesses the third-party service platform through the information query interface and sends a request message to obtain the login information of the user. The request message carries the login credentials.

[0239] For example, the request parameters of the information query interface are shown in Table 5.

[0240] Table 5. Request parameters of the information query interface

[0241] Parameter name type Is this field required? Parameter Description Token String yes Login credentials

[0242] S303_2: After the request message is verified, the login information of the object to be used is obtained from the preset object information library based on the login credentials, and the login information is encrypted and sent to the business platform so that the business platform can authenticate the login information.

[0243] After receiving a request message carrying the login credentials of the user object from the business platform to which a selected payment account belongs, the backend server of the third-party service platform verifies the login credentials carried in the request message. After the verification is passed, it queries the preset object information library based on the login credentials, obtains the login information of the user object corresponding to the login credentials, encrypts the login information, and sends it to the business platform through the information query interface.

[0244] For example, the return parameters of the information query interface are shown in Table 6.

[0245] Table 6. Return parameters of the information query interface

[0246] Parameter name type Is this field required? Parameter Description retCode String yes Response Code retMsg String yes Response information certType String yes Document type certId String yes ID number name String yes Name mobile String yes Phone number cardId String String Bank card number

[0247] After receiving the login information, the business platform decrypts it and verifies the identity of the user based on the decrypted login information. When it is verified that the payment account is the account of the user's own bank card, it is determined that the identity authentication is successful.

[0248] In one embodiment, to ensure the security of information transmission, the communication between the third-party service platform and the business platform may be transmitted via a dedicated line.

[0249] S303_3: After the identity verification is passed, jump to the system interface of the business platform.

[0250] After the business platform to which a selected payment account belongs passes the user's identity authentication, the payment account is used to log in, and the system interface after login is presented to the user, realizing the jump from the third-party service platform to the business platform.

[0251] During the first redirect, the third-party service platform interacts with the business platform of the selected payment account in response to the user's confirmation action on the authorized login interface. By sending the login credentials generated for the user to the business platform, the business platform requests the user's login information. This eliminates the need for the user to manually enter the bank card number, mobile phone number, and other information for the selected payment account for identity verification. This simplifies the user's login process, improves login efficiency, reduces the tedious process of repeatedly entering information when redirecting to different business platform system pages, and avoids login failures caused by input errors. Furthermore, the authentication mechanism in automated login enhances the security of login information and prevents information leakage. Once authentication is successful, the user is directly redirected to the business platform of the bank card of the selected payment account. This input-free authorized login process reduces the inconvenience and frustration caused by repeated operations, thereby increasing the user's frequency of use and satisfaction with the third-party service platform, and thus improving the third-party service platform's retention rate and competitiveness. Furthermore, the automated authentication process also helps to improve the security of the third-party service platform and protect the user's personal information.

[0252] In one embodiment, after the login information is encrypted and sent to the business platform to which a selected payment account belongs, the third-party service platform generates a transmission record between the third-party service platform and the business platform to which the selected payment account belongs based on the sent login information. The transmission record is used to indicate that the system interface of the business platform will be presented when subsequently jumping to the business platform for a non-first time.

[0253] like Figure 9A As shown, this is the interface effect diagram for non-first jump. When the user clicks on payment account 1 of "XX business platform, credit card number is **908" for non-first time, after the business platform verifies the login information sent by the backend server of the third-party service platform, the front-end client of the third-party service platform directly presents the homepage interface of "XX business platform".

[0254] like Figure 9BAs shown, this is the interface effect diagram for non-first jump. When the user handles the "Credit Limit Check" service for payment account 1 of "XX business platform, credit card number is **908" for the non-first time, after the business platform verifies the login information sent by the backend server of the third-party service platform, the front-end client of the third-party service platform presents a notification interface of "about to open the "XX business platform" APP", and after the user clicks "Allow" in the notification interface, it jumps to the business interface of the "Credit Limit Check" service of the XX business platform.

[0255] Optionally, the backend server of the third-party service platform may maintain a transmission record table in the database for storing transmission records between the third-party service platform and the business platform.

[0256] When the third-party service platform determines that it is not the first jump through the transmission records between it and the business platform, since the input-free authorization login confirmation has been performed during the first jump, there is no need to repeat the authorization when jumping to the system interface of a selected payment account for subsequent non-first jumps, and the input-free authorization login interface can be presented, which simplifies the subsequent login operation steps for non-first jumps.

[0257] See also Figure 10 , which is a sequence diagram of the interaction between the third-party service platform and the business platform during cross-platform jump payment, mainly includes the following steps:

[0258] S1: The front-end client of the third-party service platform responds to the platform jump operation triggered by the user for the selected payment account, and sends a credential query request of the user to the back-end server of the third-party service platform.

[0259] by Figure 7C For example, when the user clicks on the "check limit" service in the business processing interface, the front-end client sends a voucher query request to the back-end server.

[0260] S2: The backend server of the third-party service platform queries the transmission record table to obtain the transmission records between the service platform to which the selected payment account belongs.

[0261] Optionally, the transfer record may use a number to indicate the number of jumps.

[0262] For example, when jumping for the first time, the jump count in the transmission record is 0, and when jumping for the second time, the jump count in the transmission record is 1. The jump count value increases with each jump.

[0263] It should be noted that the embodiment of the present application does not impose any restrictive requirements on the form of the transmission record indicating the first jump. For example, the presence or absence of a transmission record between a third-party service platform and a business platform can also be used to indicate whether it is the first jump.

[0264] S3: When the transmission record indicates the first jump, the backend server of the third-party service platform queries the card binding table storing the binding relationship between the object and the account to determine whether the selected payment account is the bank card of the user.

[0265] When the user applies for a bank card on the business platform and agrees to bind it to the third-party service platform, the business platform will send the user and the bank card information to the third-party service platform. The third-party service platform will store the user and the payment account of the bank card in a one-to-one correspondence in the card binding table.

[0266] S4: When the selected payment account is the user's own bank card, the backend server of the third-party service platform initializes the authorization login interface and presents it to the user through the frontend client.

[0267] by Figure 7C For example, the authorization login interface includes prompt information about the business platform to which the selected payment account belongs for login without input.

[0268] S5: The front-end client of the third-party service platform responds to the confirmation operation triggered by the user object on the authorization login interface and sends an authorization login notification to the back-end server of the third-party service platform.

[0269] by Figure 7C For example, when the user clicks "Same Authorization and Go" in the authorization login interface, the front-end client sends an authorization login notification to the back-end server.

[0270] S6: The backend server of the third-party service platform generates a login credential for the user based on the authorization login notification and returns it to the frontend client of the third-party service.

[0271] The login credentials are generated by the backend server based on the object identifier, timestamp and UUID of the user on the business platform to which the selected payment account belongs.

[0272] S7: The front-end client of the third-party service platform sends an interface jump request carrying the user's login credentials. The interface jump request is submitted to the back-end server of the business platform via the front-end client of the business platform to which the selected payment account belongs.

[0273] The result of the cross-platform jump is ultimately presented to the user through an interface by the front-end client. Therefore, the front-end client of the third-party service platform sends an interface jump request to the front-end client of the business platform to which the selected payment account belongs. The interface jump request carries the login credentials of the user.

[0274] S8: The backend server of the business platform uses the login credentials as a request parameter and accesses the backend server of the third-party service platform through the information query interface.

[0275] The description of the request parameters of the information query interface is shown in Table 5 and will not be repeated here.

[0276] S9: The backend server of the third-party service platform verifies the login credentials, and after the verification is passed, queries the preset object information library to obtain the login information of the object to be used.

[0277] S10: The backend server of the third-party service platform encrypts the login information and sends it to the backend server of the business platform via a dedicated line.

[0278] The login information includes but is not limited to the user's name, ID number, mobile phone number, payment account bank card number, etc., which is transmitted to the backend server of the business platform as the return parameter of the information query interface. The description of the return parameters of the information query interface is shown in Table 6 and will not be repeated here.

[0279] S11: The backend server of the third-party service platform records the number of jumps to the service platform in a transmission record table.

[0280] S12: The backend server of the business platform decrypts the login information and verifies it.

[0281] When jumping across platforms, the business platform's acquired server verifies the login information sent by the backend server of the third-party service platform to ensure the security of the user's payment account.

[0282] S13: After the identity authentication is successful, the backend server of the business platform presents the system interface after the frontend client of the business platform logs in to the user through the frontend client of the third-party service platform.

[0283] S14: When the selected payment account is not the user's own bank card, the backend server of the third-party service platform does not generate login credentials.

[0284] When the selected payment account is not the bank card account held by the user himself, in order to ensure login security, the backend server of the third-party service platform will not transmit the login credentials to the front-end client.

[0285] S15: The front-end client of the third-party service platform sends an interface jump request without the user's login credentials. The interface jump request is submitted to the back-end server of the business platform via the front-end client of the business platform to which the selected payment account belongs.

[0286] S16: The backend server of the business platform initializes the input login interface and presents it to the user through the frontend client of the third-party service platform.

[0287] Among them, the input login interface requires the user to manually enter information such as bank card number and mobile phone number.

[0288] S17: When the transmission record indicates that it is not the first jump, the backend server of the third-party service platform does not generate login credentials.

[0289] Among them, when it is not the first jump, relying on technologies such as session management, authentication tokens, persistent login functions and caching mechanisms, the background server of the business platform can remember the login information of the user object. Therefore, there is no need to repeatedly transmit the login information, and there is no need to transmit the login credentials.

[0290] S18: The front-end client of the third-party service platform sends an interface jump request without the user's login credentials. The interface jump request is submitted to the back-end server of the business platform via the front-end client of the business platform to which the selected payment account belongs.

[0291] S19: The backend server of the business platform initializes the input login interface and presents it to the user through the frontend client of the third-party service platform.

[0292] In order to achieve cross-platform payment interface jumps, the third-party service platform has developed an information query interface based on a unified open API protocol to ensure compatibility and interoperability with different business platforms and reduce the complexity of system integration. Through this interface, the third-party service platform receives request messages from the business platform carrying the login credentials of the user, and returns a response message carrying the login information corresponding to the login credentials to the business platform, thereby realizing an automatic login mechanism that does not require information input during the first jump, improving the efficiency of the login operation, and not only reducing the tedious operation of users repeatedly entering information when jumping to system pages of different business platforms, but also enabling cooperation with multiple business platforms at a lower development cost, rapidly expanding the scale of users, and thus enhancing market competitiveness. In addition, the open API protocol helps third-party service platforms quickly respond to market changes, launch new functions and services, and enhance business development capabilities.

[0293] To ensure the security of information transmission, the information query interface can adopt the encryption and decryption algorithms in the open API protocol.

[0294] Optionally, the information query interface may adopt mixed encryption of multiple encryption algorithms in the open API protocol, such as mixed encryption of SM2 algorithm and SM4 algorithm.

[0295] In one embodiment, when the third-party service platform and the business platform develop an information query interface, they can exchange and store the public-private key pairs generated by each for signature verification. That is, the third-party service platform stores the public-private key pair generated by the business platform for signature verification. At the same time, the business platform also stores the public-private key pair generated by the third-party service platform for signature verification.

[0296] Among them, the public-private key pair generated by the business platform for signature verification is recorded as the business public-private key pair, which includes a business private key and a business public key; the public-private key pair generated by the third-party service platform for signature verification is recorded as the service public-private key pair, which includes a service private key and a service public key.

[0297] In one embodiment, the original signature of the request message carrying login credentials sent by the business platform through the information query interface is encrypted using the business private key of the business platform. At this time, the third-party service platform's verification process for the request message is: based on the pre-stored business public key of the business platform, a new signature of the request message is regenerated, and the original signature and the new signature are compared. When the comparison results are the same, it is determined that the request message verification has passed.

[0298] Because the original signature of the request message carrying the login credentials uses the business platform's private key, upon receiving the request message, the third-party service platform verifies the signature using the business platform's public key. By encrypting and decrypting the signature, the security and reliability of information transmission are improved.

[0299] In one embodiment, the request message carrying login credentials sent by the business platform through the information query interface is encrypted using the first key of the business platform, wherein the first ciphertext of the first key is obtained by the business platform encrypting the first ciphertext of the first key using the pre-stored service public key of the third-party service platform. Therefore, after receiving the request message, the backend server of the third-party service platform first uses the service private key to decrypt the first ciphertext of the first key to obtain the first key, and then uses the decrypted first key to decrypt the request message to obtain the request data for obtaining the login information of the user object.

[0300] When the business platform requests data through the information query interface, it encrypts the request message carrying the login credentials and the first key of the encrypted request message. Through double encryption, the login credentials are prevented from being tampered with, thereby ensuring the security of login without entering information.

[0301] In one embodiment, the third-party service platform obtains the login information of the object to be used from a preset object information library based on the login credentials carried in the request message, encrypts the login information based on the second key, obtains a response message corresponding to the request message, and uses the pre-stored business public key of the business platform to encrypt the second ciphertext to obtain the second ciphertext of the second key, and then uses its own service private key to encrypt the signature of the response message, and sends the encrypted response message to the business platform.

[0302] When the third-party service platform returns data through the information query interface, the login information and signature of the response message are encrypted separately. Through the mixed encryption of data and signature, the login information is prevented from being tampered with, ensuring the confidentiality, integrity and security of the data.

[0303] See also Figure 11 ,The schematic diagram of the encrypted transmission process of login information through the information query interface, the specific process is as follows:

[0304] S1: The service platform uses a first key generated by itself to encrypt the request message carrying the login credentials.

[0305] Optionally, the first key is a key randomly generated by the service platform using the SM4 algorithm.

[0306] S2: The business platform uses the pre-stored service public key of the third service platform to encrypt the first key to generate a first ciphertext of the first key.

[0307] Optionally, the service public key of the third-party service platform is a public key generated using the SM2 algorithm.

[0308] S3: The business platform uses its own business private key to encrypt the signature of the request message.

[0309] Optionally, the business public key of the business platform is a public key generated using the SM2 algorithm.

[0310] S4: The business platform sends an encrypted request message to the third-party service platform.

[0311] S5: The third-party service platform uses the pre-stored business public key of the business platform to verify the signature of the request message.

[0312] By verifying the signature, data is prevented from being tampered with to ensure that the login credentials received by the third-party service platform are exactly the same as the login credentials sent by the business platform.

[0313] S6: When the signature verification is successful, the third-party service platform uses its own service private key to decrypt the first ciphertext and obtain the first key.

[0314] Optionally, the service private key of the third-party service platform is a public key generated using the SM2 algorithm.

[0315] S7: The third-party service platform uses the first key to decrypt the request message to obtain a login credential for obtaining the login information.

[0316] In the information query interface, the login credentials are hybrid encrypted using the SM2 algorithm and the SM4 algorithm, which improves the security of login credential transmission.

[0317] S8: The third-party service platform obtains login information based on the decrypted login credentials.

[0318] The third-party service platform queries the preset object information database to obtain the login information submitted by the user when applying for a bank card.

[0319] S9: The third-party service platform encrypts the login information using the second key generated by itself to obtain a response message.

[0320] Optionally, the second key is randomly generated by the third-party service platform using the SM4 algorithm.

[0321] S10: The third-party service platform encrypts the second key using the pre-stored business public key of the business platform to obtain a second ciphertext of the second key.

[0322] S11: The third-party service platform uses its own service private key to encrypt the signature of the response message.

[0323] S12: The third-party service platform sends the encrypted response message to the business platform.

[0324] S13: The business platform uses its own business private key to verify the signature of the response message.

[0325] S14: After the signature verification is passed, the business platform uses its own business private key to decrypt the second ciphertext to obtain the second key.

[0326] By verifying the signature, data is prevented from being tampered with, ensuring that the login information received by the business platform is exactly the same as the login information sent by the third-party service platform.

[0327] S15: The service platform decrypts the response message using the second key to obtain login information.

[0328] In the information query interface, the signature and data of the login information are hybrid encrypted using the SM2 algorithm and the SM4 algorithm to prevent the login information from being tampered with, ensuring the confidentiality, integrity and security of the login information. At the same time, it improves encryption performance and scalability and simplifies key management.

[0329] In one embodiment, for bank card payment account binding and cross-platform payment interface jump processes, the interaction between the third-party service platform and the business platform can use Hypertext Transfer Protocol Secure (HTTPS) to ensure the security of the information transmission process. The request header content of the HTTPS protocol is shown in Table 7.

[0330] Table 7. HTTPS request header

[0331]

[0332] In the embodiments of the present application, the binding of bank card payment accounts and the jump to cross-platform payment interfaces are realized through the account binding interface and the information query interface, which significantly reduces the information input steps when the user binds the payment accounts of bank cards of multiple bank systems on the third-party service platform, as well as the information input steps when jumping to the bank system to which a bound payment account belongs. This helps the user to conveniently manage multiple bank cards in one stop, provides more convenient and secure services, thereby improving the reliability and user experience of the third-party service platform, reducing the development cost and maintenance cost of docking with information of different banks, bringing greater commercial value and competitive advantage to the third-party service platform, and has broad market prospects.

[0333] Based on the same inventive concept, an embodiment of the present application provides a cross-platform jump payment device, which can implement the above-mentioned cross-platform jump payment method and achieve the same technical effect.

[0334] like Figure 12 , which is a schematic diagram of the structure of a cross-platform jump payment device, including a first presentation unit 1201, a second presentation unit 1202 and a third presentation unit 1203, wherein:

[0335] The first presentation unit 1201 is configured to present an account interface in response to a payment service entry operation triggered by a user; the account interface includes at least one payment account bound to the user on a third-party service platform;

[0336] The second presentation unit 1202, in response to a selection operation triggered by the user for at least one payment account, presents an authorization login interface associated with the selected payment account; the authorization login interface is generated when the user first jumps to the business platform to which the selected payment account belongs;

[0337] The third presentation unit 1203 jumps to the system interface of the business platform to which the selected payment account belongs in response to the confirmation operation triggered by the user on the authorization login interface.

[0338] Optionally, the third presenting unit 1203 is specifically configured to:

[0339] In response to a first confirmation operation triggered by the user on the authorization login interface, a notification interface is presented; the notification interface includes an opening method for jumping to a business platform to which a selected payment account belongs;

[0340] In response to the user's second confirmation operation on the opening method in the notification interface, the interface jumps to the system interface of the business platform to which the selected payment account belongs.

[0341] Optionally, the second presenting unit 1202 is specifically configured to:

[0342] In response to a first selection operation triggered by a user on at least one payment account, a business processing interface associated with the selected payment account is presented; the business processing interface includes: at least one business that a third-party service platform cooperates with a business platform to which the selected payment account belongs;

[0343] In response to a second selection operation triggered by the user for at least one business, an authorization login interface associated with a selected payment account is presented; the second selection operation is triggered when the user handles a business that requires external jump for the first time on a third-party service platform.

[0344] Optionally, the third presenting unit 1203 is specifically configured to:

[0345] In response to a confirmation operation triggered by the user on the authorized login interface, generating a login credential for the user, and sending the login credential to a business platform to which a selected payment account belongs, so that the business platform sends a request message for obtaining the user's login information;

[0346] After the request message is verified, the login information of the object to be used is obtained from the preset object information library based on the login credentials carried in the request message, and the login information is encrypted and sent to the business platform so that the business platform can authenticate the login information and log in;

[0347] After the verification is passed, jump to the system interface of the business platform.

[0348] Optionally, the original signature of the request message is encrypted using the service private key of the service platform, and the third presentation unit 1203 is specifically configured to:

[0349] Regenerate a new signature for the request message based on the pre-stored business public key of the business platform;

[0350] The original signature and the new signature are compared. If the comparison results are the same, the request message is considered to have passed verification.

[0351] Optionally, the request message is encrypted using a first key generated by the service platform, and the third presentation unit 1203 is specifically configured to:

[0352] The first ciphertext of the first key is decrypted using the service private key to obtain the first key; the first ciphertext is obtained by: the business platform encrypts the first ciphertext using the pre-stored service public key of the third-party service platform;

[0353] The request message is decrypted using the first key to obtain request data for obtaining login information.

[0354] Optionally, the third presenting unit 1203 is specifically configured to:

[0355] Encrypt the login information based on the second key to obtain a response message;

[0356] Encrypting the second key using the pre-stored business public key of the business platform to obtain a second ciphertext of the second key;

[0357] The signature of the response message is encrypted using the service private key, and the encrypted response message is sent to the business platform.

[0358] Optionally, the third presenting unit 1203 is further configured to:

[0359] Based on the sent login information, a transmission record is generated between the business platform to which the selected payment account belongs; the transmission record is used to indicate that the system interface of the business platform will be presented when the subsequent jump to the business platform is not the first time.

[0360] Optionally, the device further includes a real-name authentication unit 1204, specifically configured to:

[0361] Performing real-name authentication on the user based on the user's identity information;

[0362] When the real-name authentication is successful, the identity information is encrypted and associated with the object identifier of the user on different business platforms and stored in the preset object information library.

[0363] Optionally, the second presenting unit 1203 is specifically configured to:

[0364] In response to a selection operation triggered by a user object for at least one payment account, querying a transmission record with a business platform to which the selected payment account belongs;

[0365] When the transmission record indicates the first jump to the business platform, query the binding relationship between the object and the account. The binding relationship includes at least one payment account that the object is bound to.

[0366] When a selected payment account satisfies a binding relationship with the user object, an authorization login interface associated with the selected payment account is presented.

[0367] Optionally, the device further includes an account binding unit 1205, specifically configured to:

[0368] For at least one payment account, perform the following operations:

[0369] When a user applies for a payment account and authorizes binding, the user receives the login information of the user sent by the business platform to which the payment account belongs.

[0370] Based on the login information, the preset object information library is searched to obtain the object identifier of the usage object in the business platform to which a payment account belongs;

[0371] Bind an object identifier to a payment account.

[0372] With the above-mentioned cross-platform jump device, as soon as the user enters the payment service, the third-party service platform will present an account interface containing at least one payment account bound by the user on the platform. The user does not need to manually enter information for account binding, which reduces the account binding process and effectively improves the convenience of the account binding operation; for at least one payment account that has been bound in the account interface, when jumping to the business platform to which a payment account selected by the user belongs for the first time, the third-party service platform presents the authorization login interface associated with the selected payment account. Furthermore, when the user confirms the authorized login operation, the user does not need to manually enter login information for identity authentication, and the third-party service platform can jump to the system interface of the business platform to which the selected payment account belongs, reducing the input operation during the first cross-platform interface jump, effectively improving the operation convenience and response speed of the first cross-platform interface jump, thereby effectively improving the service experience of the user and increasing the retention rate and competitiveness of the third-party service platform.

[0373] For the convenience of description, the above parts are divided into modules (or units) according to their functions and described separately. Of course, when implementing this application, the functions of each module (or unit) can be implemented in the same or multiple software or hardware.

[0374] Regarding the cross-platform jump device in the above embodiment, the specific manner in which each unit executes the request has been described in detail in the embodiment of the method, and will not be elaborated here.

[0375] Those skilled in the art will appreciate that various aspects of the present application can be implemented as systems, methods, or program products. Therefore, various aspects of the present application can be specifically implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation that combines hardware and software aspects, which may be collectively referred to herein as a "circuit," "module," or "system."

[0376] Based on the same inventive concept, an embodiment of the present application further provides an electronic device. In one embodiment, the electronic device may be a backend server of a third-party service platform.

[0377] See Figure 13 As shown, it is a schematic diagram of the structure of a possible electronic device provided in an embodiment of the present application. Figure 13 In the embodiment, the electronic device includes: a memory 1301 , a communication module 1303 and one or more processors 1302 .

[0378] The memory 1301 is used to store computer programs executed by the processor 1302. The memory 1301 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and an operating instruction set.

[0379] Memory 1301 may be a volatile memory, such as random-access memory (RAM); a non-volatile memory, such as read-only memory, flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or any other medium capable of carrying or storing a desired computer program in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1301 may be a combination of the aforementioned memories.

[0380] The processor 1302 may include one or more central processing units (CPUs) or digital processing units, etc. The processor 1302 is configured to implement the steps of the above-mentioned cross-platform jump method when calling the computer program stored in the memory 1301 .

[0381] The communication module 1303 is used to communicate with the server and the terminal device.

[0382] The specific connection medium between the memory 1301, the communication module 1303 and the processor 1302 is not limited in the embodiment of the present application. Figure 13 In the embodiment, the memory 1301 and the processor 1302 are connected via a bus 1304. The bus 1304 is connected to the processor 1302 via a bus 1304. Figure 13 The connections between the other components are shown in bold lines, which are only for illustration and are not intended to be limiting. The bus 1304 can be divided into an address bus, a data bus, a control bus, etc. For ease of description, Figure 13 The diagram shows a single thick line, but this does not indicate that there is only one bus or one type of bus.

[0383] The memory 1301 stores a computer storage medium, which stores computer executable instructions for implementing the cross-platform jump method of the embodiment of the present application. The processor 1302 is used to execute the steps of the cross-platform jump method.

[0384] Based on the same inventive concept, an embodiment of the present application further provides a terminal device. In one embodiment, the terminal device can carry a front-end client of a third-party service platform.

[0385] See Figure 14 As shown, it is a structural diagram of a possible terminal device provided in an embodiment of the present application. Figure 14 In the embodiment, the terminal device includes: a communication component 1410, a memory 1420, a display unit 1430, a camera 1440, a sensor 1450, an audio circuit 1460, a Bluetooth module 1470, a processor 1480 and other components.

[0386] The communication component 1410 is used to communicate with the server. In some embodiments, it may include a wireless fidelity (WiFi) module. The WiFi module is a short-range wireless transmission technology. The electronic device can help the object send and receive information through the WiFi module.

[0387] The memory 1420 can be used to store software programs and data. The processor 1480 executes various functions and data processing of the terminal device by running the software programs or data stored in the memory 1420. The memory 1420 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. The memory 1420 stores the operating system that enables the terminal device to operate. In the present application, the memory 1420 can store the operating system and various application programs, and may also store the computer program that executes the cross-platform jump method of the embodiment of the present application.

[0388] Display unit 1430 can also be used to display information input by or provided to an object, as well as a graphical object interface of various menus. Specifically, display unit 1430 may include display screen 1432. Display screen 1432 may be configured in the form of a liquid crystal display, light-emitting diode, etc. Display unit 1430 can be used to display the operation interface in the embodiments of the present application.

[0389] The display unit 1430 can also be used to receive input digital or character information and generate signal input related to the object setting and function control of the terminal device. Specifically, the display unit 1430 may include a touch screen 1431 set in the terminal device, which can collect touch operations of objects on or near it, such as clicking a button, dragging a scroll box, etc.

[0390] The touch screen 1431 can be covered on the display screen 1432, or the touch screen 1431 and the display screen 1432 can be integrated to realize the input and output functions of the terminal device, and the integrated display screen can be simply called a touch display screen. In this application, the display unit 1430 can display applications and corresponding operation steps.

[0391] Camera 1440 can be used to capture images. There can be one or more cameras 1440. The object is projected through the lens to generate an optical image, which is then projected onto a photosensitive element. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal oxide semiconductor (CMOS) phototransistor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transmitted to processor 1480 for conversion into a digital image signal.

[0392] The terminal device may further include at least one sensor 1450, such as an acceleration sensor 1451, a distance sensor 1452, a fingerprint sensor 1453, and a temperature sensor 1454. The terminal device may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, a light sensor, and a motion sensor.

[0393] The audio circuit 1460, speaker 1461, and microphone 1462 provide an audio interface between the subject and the terminal device. The audio circuit 1460 converts the received audio data into an electrical signal and transmits it to the speaker 1461, which converts it into a sound signal for output. The terminal device may also be equipped with a volume button for adjusting the volume of the sound signal. Meanwhile, the microphone 1462 converts the collected sound signal into an electrical signal, which is received by the audio circuit 1460 and converted into audio data. The audio data is then output to the communication component 1410 or to the memory 1420 for further processing.

[0394] The Bluetooth module 1470 is used to exchange information with other Bluetooth devices having a Bluetooth module through the Bluetooth protocol. For example, the terminal device can establish a Bluetooth connection with a wearable electronic device (such as a smart watch) that also has a Bluetooth module through the Bluetooth module 1470 to exchange data.

[0395] The processor 1480 is the control center of the terminal device. It uses various interfaces and lines to connect various parts of the entire terminal. By running or executing software programs stored in the memory 1420 and calling data stored in the memory 1420, it performs various functions of the terminal device and processes data. In some embodiments, the processor 1480 may include one or more processing units; the processor 1480 may also integrate an application processor and a baseband processor, wherein the application processor mainly processes the operating system, object interface and application programs, etc., and the baseband processor mainly processes wireless communications. It is understandable that the above-mentioned baseband processor may not be integrated into the processor 1480. In the present application, the processor 1480 can run the operating system, application programs, object interface display and touch response, as well as the cross-platform jump method of the embodiment of the present application. In addition, the processor 1480 is coupled to the display unit 1430.

[0396] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which includes a computer program. When the computer program runs on an electronic device, the computer program is used to enable the electronic device to execute the steps of the above-mentioned cross-platform jump method.

[0397] In some possible implementations, various aspects of the cross-platform jump method provided in this application may also be implemented in the form of a program product, which includes a computer program. When the program product is run on an electronic device, the computer program is used to enable the electronic device to perform the steps of the above-mentioned cross-platform jump method. For example, the electronic device may perform the following steps: Figure 3 Follow the steps shown in .

[0398] The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, RAM, ROM, an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0399] The program product of the embodiments of the present application may be a CD-ROM and include a computer program, and may be run on an electronic device. However, the program product of the present application is not limited thereto. In this document, a readable storage medium may be any tangible medium that contains or stores a computer program that can be used by or in conjunction with a command execution system, apparatus, or device.

[0400] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries a readable computer program. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a computer program for use by or in conjunction with a command execution system, apparatus, or device.

[0401] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0402] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A cross-platform jump payment method, characterized in that: include: In response to a payment service entry operation triggered by the usage object, presenting an account interface; The account interface includes: at least one payment account bound by the user on the third-party service platform; In response to a selection operation triggered by the user for the at least one payment account, presenting an authorization login interface associated with the selected payment account; The authorization login interface is generated when jumping to the business platform to which the selected payment account belongs for the first time; In response to the confirmation operation triggered by the user object on the authorization login interface, the system interface of the business platform to which the selected payment account belongs is jumped.

2. The method according to claim 1, wherein The step of jumping to the system interface of the business platform to which the selected payment account belongs in response to the confirmation operation triggered by the user on the authorization login interface includes: In response to the first confirmation operation triggered by the user on the authorization login interface, presenting a notification interface; the notification interface includes an opening method for jumping to the business platform to which the selected payment account belongs; In response to the second confirmation operation of the user object on the opening method in the notification interface, jump to the system interface of the business platform to which the selected payment account belongs.

3. The method according to claim 1, wherein The presenting, in response to the selection operation triggered by the user for the at least one payment account, an authorization login interface associated with the selected payment account, includes: In response to a first selection operation triggered by the user on the at least one payment account, presenting a service processing interface associated with the selected payment account; the service processing interface includes: at least one service that the third-party service platform cooperates with the service platform to which the selected payment account belongs; In response to the second selection operation triggered by the user for the at least one business, an authorization login interface associated with the selected payment account is presented; the second selection operation is triggered when the user handles a business that requires an external jump for the first time on the third-party service platform.

4. The method according to claim 1 or 2, wherein: The step of jumping to the system interface of the business platform to which the selected payment account belongs in response to the confirmation operation triggered by the user on the authorization login interface includes: In response to a confirmation operation triggered by the user on the authorized login interface, generating a login credential for the user, and sending the login credential to a business platform to which a selected payment account belongs, so that the business platform sends a request message for obtaining the login information of the user; After the request message is verified, the login information of the user object is obtained from the preset object information library based on the login credentials carried in the request message, and the login information is encrypted and sent to the service platform, so that the service platform authenticates the login information; After the verification is passed, jump to the system interface of the business platform.

5. The method according to claim 4, wherein The original signature of the request message is encrypted using the service private key of the service platform, and the request message is verified in the following manner: Regenerate a new signature for the request message based on the pre-stored business public key of the business platform; The original signature and the new signature are compared, and when the comparison results are the same, it is determined that the request message has passed the verification.

6. The method according to claim 4, wherein The request message is encrypted using the first key generated by the service platform, and the decryption process of the request message includes: Decrypting the first ciphertext of the first key using the service private key to obtain the first key; the first ciphertext is obtained by: the business platform encrypting the first ciphertext using the pre-stored service public key of the third-party service platform; The request message is decrypted using the first key to obtain request data for obtaining the login information.

7. The method according to claim 4, wherein The step of encrypting the login information and sending it to the service platform includes: Encrypting the login information based on the second key to obtain a response message; Encrypting the second key using a pre-stored service public key of the service platform to obtain a second ciphertext of the second key; The signature of the response message is encrypted using the service private key, and the encrypted response message is sent to the service platform.

8. The method according to claim 4, wherein After encrypting the login information and sending it to the service platform, the method further includes: Based on the sent login information, a transmission record is generated between the business platform to which the selected payment account belongs; the transmission record is used to indicate that when the business platform is subsequently jumped to for the second time, the system interface of the business platform is presented.

9. The method according to claim 4, wherein The preset object information library is obtained in the following manner: Performing real-name authentication on the user based on the user's identity information; When the real-name authentication is successful, the identity information is encrypted and associated with the object identifier of the user on different business platforms, and stored in the preset object information library.

10. The method according to claim 1 or 3, wherein: The presenting, in response to the selection operation triggered by the user for the at least one payment account, an authorization login interface associated with the selected payment account, includes: In response to a selection operation triggered by the user for the at least one payment account, querying a transmission record with a business platform to which the selected payment account belongs; When the transmission record indicates the first jump to the service platform, querying the binding relationship between the object and the account, the binding relationship includes at least one payment account to which the object is bound; When the selected payment account and the usage object satisfy the binding relationship, an authorization login interface associated with the selected payment account is presented.

11. The method according to any one of claims 1 to 3, wherein The account interface contains at least one payment account, which is bound in the following way: For the at least one payment account, perform the following operations respectively: When the user applies for a payment account and authorizes binding, the user receives the login information of the user sent by the service platform to which the payment account belongs. Querying a preset object information database based on the login information to obtain an object identifier of the user object in the business platform to which the payment account belongs; Binding the object identifier to the one payment account.

12. A cross-platform jump payment device, characterized in that: include: a first presentation unit, configured to present an account interface in response to a payment service entry operation triggered by a usage object; The account interface includes: at least one payment account bound by the user on the third-party service platform; a second presentation unit, configured to present an authorization login interface associated with a selected payment account in response to a selection operation triggered by the user on the at least one payment account; The authorization login interface is generated when jumping to the business platform to which the selected payment account belongs for the first time; The third presentation unit jumps to the system interface of the business platform to which the selected payment account belongs in response to the confirmation operation triggered by the user on the authorization login interface.

13. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor is enabled to perform the steps of any one of the methods of claims 1 to 11.

14. A computer-readable storage medium, characterized in that The method comprises a computer program. When the computer program is run on an electronic device, the computer program is used to enable the electronic device to execute the steps of any one of the methods of claims 1 to 11.

15. A computer program product, characterized in that It includes a computer program, which is stored in a computer-readable storage medium. A processor of an electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device performs the steps of any method described in claims 1 to 11.

Images