WO2021143547A1 - 会话建立方法、跨境支付方法、装置及系统 - Google Patents

会话建立方法、跨境支付方法、装置及系统 Download PDF

Info

Publication number
WO2021143547A1
WO2021143547A1 PCT/CN2020/142515 CN2020142515W WO2021143547A1 WO 2021143547 A1 WO2021143547 A1 WO 2021143547A1 CN 2020142515 W CN2020142515 W CN 2020142515W WO 2021143547 A1 WO2021143547 A1 WO 2021143547A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
log
request
central server
identifier
Prior art date
Application number
PCT/CN2020/142515
Other languages
English (en)
French (fr)
Inventor
郑君华
Original Assignee
支付宝实验室(新加坡)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝实验室(新加坡)有限公司 filed Critical 支付宝实验室(新加坡)有限公司
Publication of WO2021143547A1 publication Critical patent/WO2021143547A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Definitions

  • This article relates to the field of Internet technology, in particular to a session establishment method, cross-border payment method, device and system.
  • the session establishment process provided in the prior art is mainly: the client directly calls the central server to log in based on the user identification, so as to establish a trusted session between the client and the central server. In this process, due to the user identification The credibility is relatively low, and secure login cannot be achieved.
  • the purpose of one or more embodiments of this specification is to provide a session establishment method.
  • the client communicates with the central server, and the session establishment method includes: after detecting a preset service trigger operation for the payment application installed on the client, determining whether there is a session identifier locally . If there is no session identifier, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server for the authorized log-in request of the client. If there is a log-in retention identifier, based on the log-in retention identifier, a log-in retention request is sent to the central server, so that the central server responds to the log-in retention request and establishes trust with the client Conversation.
  • the purpose of one or more embodiments of this specification is to provide a session establishment method.
  • the central server communicates with a client, and the session establishment method includes: receiving a log-in hold request from the client, wherein the log-in hold request carries a locally pre-stored log-in identification, said The keep-login identifier is sent by the central server in response to the client's authorized login request.
  • a trust session with the client is established based on the log-in retention identifier.
  • the purpose of one or more embodiments of this specification is to provide a cross-border payment method.
  • the client is in communication connection with the central server, and the cross-border payment method includes: after detecting a preset service trigger operation for the payment application installed on the client, judging whether there is a session identifier locally symbol. If there is no session identifier, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server for the authorized log-in request of the client.
  • a log-in retention request is sent to the central server, so that the central server responds to the log-in retention request and establishes trust with the client Conversation.
  • the purpose of one or more embodiments of this specification is to provide a cross-border payment method.
  • the central server communicates with a client, and the cross-border payment method includes: receiving a log-in request from the client, wherein the log-in request carries a locally pre-stored log-in identifier, so The log-in retention identifier is sent by the central server for the authorized log-in request of the client.
  • a trust session with the client is established based on the log-in retention identifier.
  • the purpose of one or more embodiments of this specification is to provide a session establishment device.
  • the client communicates with the central server, and the session establishment device includes: a first judging module, which judges after detecting a preset service trigger operation for the payment application installed on the client Whether there is a session identifier locally.
  • the second judging module if there is no session identifier, judge whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server for the authorization log-in request of the client.
  • the session establishment module if there is a log-in retention identifier, based on the log-in retention identifier, sends a log-in retention request to the central server, so that the central server responds to the log-in retention request and establishes a connection with the client Trusted session between terminals.
  • the purpose of one or more embodiments of this specification is to provide a session establishment device.
  • the central server is in communication connection with the client
  • the session establishment device includes: a keep-login request receiving module, which receives a keep-login request from the client, wherein the keep-login request carries a local pre-stored The log-in retention identifier, which is sent by the central server for the authorized log-in request of the client.
  • a trusted session establishment module which, in response to the keep-login request, establishes a trust session with the client based on the keep-login identifier.
  • the purpose of one or more embodiments of this specification is to provide a cross-border payment device.
  • the client terminal is in communication with the central server terminal, and the cross-border payment device includes: a first judgment module, which, after detecting a preset service trigger operation for the payment application installed on the client terminal, Determine whether there is a session identifier locally.
  • the second judging module if there is no session identifier, judge whether there is a log-in retention identifier locally, wherein the log-in retention identifier is sent by the central server for the authorization log-in request of the client.
  • the session establishment module if there is a log-in retention identifier, based on the log-in retention identifier, sends a log-in retention request to the central server, so that the central server responds to the log-in retention request and establishes a connection with the client Trusted session between terminals.
  • a cross-border payment request sending module which sends a cross-border payment request to the central server, so that the central server responds to the cross-border payment request and executes a corresponding cross-border payment operation.
  • the purpose of one or more embodiments of this specification is to provide a cross-border payment device.
  • the central server is in communication connection with the client, and the cross-border payment device includes: a keep-login request receiving module, which receives a keep-login request from the client, wherein the keep-login request carries a local A pre-stored log-in retention identifier, where the log-in retention identifier is sent by the central server for the authorization log-in request of the client.
  • a trusted session establishment module which, in response to the keep-login request, establishes a trust session with the client based on the keep-login identifier.
  • the cross-border payment processing module receives the cross-border payment request sent by the client, and executes the corresponding cross-border payment operation.
  • the purpose of one or more embodiments of this specification is to provide a session establishment system, including: a client and a central server, and the client is in communication connection with the central server.
  • the client includes the above-mentioned session establishment device including a first judgment module, a second judgment module, and a session establishment module.
  • the central server includes the above-mentioned session establishment device including a keep-login request receiving module and a trusted session establishment module.
  • the purpose of one or more embodiments of this specification is to provide a cross-border payment system, including: a client and a central server, and the client is in communication connection with the central server.
  • the client terminal includes the above-mentioned cross-border payment device including a first judgment module, a second judgment module, a session establishment module, and a payment request sending module.
  • the central server includes the above-mentioned cross-border payment device including a keep-login request receiving module, a trust session establishment module, and a cross-border payment processing module.
  • the purpose of one or more embodiments of this specification is to provide a session establishment device including: a processor; and a memory arranged to store computer-executable instructions.
  • the processor determines whether there is a session identifier locally after detecting a preset service trigger operation for the payment application installed on the client. If there is no session identifier, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server for the authorized log-in request of the client. If there is a log-in retention identifier, based on the log-in retention identifier, a log-in retention request is sent to the central server, so that the central server responds to the log-in retention request and establishes trust with the client Conversation.
  • the purpose of one or more embodiments of this specification is to provide a session establishment device including: a processor; and a memory arranged to store computer-executable instructions.
  • the processor receives a keep-login request from the client, wherein the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is the central service Sent by the client for an authorized login request of the client.
  • the processor receives a keep-login request from the client, wherein the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is the central service Sent by the client for an authorized login request of the client.
  • a trust session with the client is established based on the log-in retention identifier.
  • the purpose of one or more embodiments of this specification is to provide a storage medium for storing computer-executable instructions.
  • the executable instruction When the executable instruction is executed by the processor, after detecting a preset service trigger operation for the payment application installed on the client, it is determined whether there is a session identifier locally. If there is no session identifier, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server for the authorized log-in request of the client. If there is a log-in retention identifier, based on the log-in retention identifier, a log-in retention request is sent to the central server, so that the central server responds to the log-in retention request and establishes trust with the client Conversation.
  • the purpose of one or more embodiments of this specification is to provide a storage medium for storing computer-executable instructions.
  • the executable instruction When the executable instruction is executed by the processor, a request to keep logging in from the client is received, wherein the request to keep logging in carries a locally pre-stored keep logging in identifier, and the keeping logging in identifier is for the central server to respond to the Sent by the client's authorized login request.
  • a trust session with the client is established based on the log-in retention identifier.
  • FIG. 1 is a schematic diagram of an application scenario of a session establishment system provided by one or more embodiments of this specification;
  • FIG. 2 is a schematic diagram of the first flow of a session establishment method provided by one or more embodiments of this specification;
  • FIG. 3 is a schematic diagram of the second flow of the session establishment method provided by one or more embodiments of this specification.
  • FIG. 4 is a schematic diagram of the third process of the session establishment method provided by one or more embodiments of this specification.
  • FIG. 5 is a first schematic diagram of the information interaction process between the client and the central server in the session establishment method provided by one or more embodiments of this specification;
  • FIG. 6 is a schematic diagram of the fourth flow of the session establishment method provided by one or more embodiments of this specification.
  • FIG. 7 is a second schematic diagram of the information interaction process between the client and the central server in the session establishment method provided by one or more embodiments of this specification;
  • FIG. 8 is a schematic diagram of the fifth flow of the session establishment method provided by one or more embodiments of this specification.
  • FIG. 9 is a schematic flowchart of a method for establishing a session in which the execution subject is the central server provided by one or more embodiments of this specification;
  • FIG. 10 is a schematic flowchart of a cross-border payment method provided by one or more embodiments of this specification in which the execution subject is a client;
  • FIG. 11 is a schematic flowchart of a cross-border payment method in which the execution subject is the central server provided by one or more embodiments of this specification;
  • FIG. 12 is a schematic diagram of the module composition of a session establishment apparatus provided on a client provided by one or more embodiments of this specification;
  • FIG. 13 is a schematic diagram of the module composition of the session establishment device provided on the central server according to one or more embodiments of this specification;
  • FIG. 14 is a schematic structural diagram of a session establishment device provided by one or more embodiments of this specification.
  • One or more embodiments of this specification provide a session establishment method, cross-border payment method, device, and system.
  • the central The server sends the corresponding session identifier and the keep-login ID to the client at the same time, so that the subsequent client directly requests to keep logged in based on the keep-login ID, so that there is no need to perform the complicated interactive process of authorized login during the valid period of the keep-login ID, which reduces authorization
  • the call frequency of login simplifies the interaction steps of establishing a trust session between the client and the central server, which not only ensures that the client can safely log in to the SAAS service of the central server, but also improves the efficiency of the client's secure login.
  • Fig. 1 is a schematic diagram of an application scenario of a session establishment system provided by one or more embodiments of this specification.
  • the system includes: a central server, multiple clients, and multiple payment servers.
  • the client can be a mobile terminal such as a smart phone, a tablet computer, etc.
  • the client can also be a terminal device such as an Internet of Things device
  • the client can be a user terminal used by a consumer, or a user terminal described by a merchant.
  • the client is provided with a preset software development kit SDK, and is connected to the global network GN (that is, the Alipay GlobalNet network) through the SDK to communicate with the central server.
  • GN that is, the Alipay GlobalNet network
  • the central server can be a back-end server that supports the interconnection of payment applications in different countries through the global network GN, so as to realize cross-border payments on the client side.
  • the central server can be an independent server with saas services. It can also be a server cluster composed of multiple servers with saas services.
  • the payment server can be a back-end server used to manage and control the payment applications installed on the client.
  • the payment server is connected to the global network GN to communicate with the central server. Different payment servers use their respective payment applications as The client provides payment services.
  • Payment applications are cross-border payments between consumers and merchants. At this time, a trust session needs to be established between the client and the central server, and then the central server interacts with the corresponding payment server of the consumer and the merchant. This enables cross-border payments between consumers and merchants.
  • the specific process of establishing a session between the client and the central server is as follows: after the client detects the user’s preset service triggering operation for the payment application, it determines whether the session identifier sessionId exists locally; if the client determines that the local If there is a session identifier sessionId, a cross-border payment request carrying the session identifier sessionId is sent to the central server, so that the central server responds to the client's cross-border payment request based on the session identifier sessionId and sends the corresponding If the client determines that the session identifier sessionId does not exist locally, it will determine whether there is a login-maintaining identifier clientKey locally.
  • the client sends a login request to the central server based on the clientKey; the central server responds to the client's login request to keep the login request carried Keep the login identifier clientKey for legality verification; if the central server determines that the clientKey has passed the legality verification, it returns a new session identifier sessionId to the client; the client receives the new session identifier sessionId returned by the central server Establish a trusted session with the central server based on the sessionId.
  • the client sends an authorized login request to the central server based on the authorization authentication code issued by the payment server corresponding to the payment application; the central server responds to the client's authorized login request , Request the payment server corresponding to the payment application to verify the validity of the authorization verification code; if the central server receives the result of the verification of the authorization verification code, it returns a new session identifier sessionId and Keep the login ID clientKey; after the client receives the new session ID sessionId and keep the login ID clientKey, it establishes a trust session with the central server based on the sessionId, and stores the clientKey, where subsequent clients can send to the center based on the clientKey
  • the server requests to keep logged in, so that a trust session is established between the client and the central server, that is, a trust session between the SDK of the client and the SAAS service of the central server is established.
  • the central server in the process of establishing a trust session between the client and the central server, during the client request authorization login phase, the central server simultaneously sends the corresponding session identifier to the client and keeps logging in Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trusted session between them can not only ensure that the client with the SDK connected to the GN can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • Fig. 2 is a schematic diagram of the first flow of the session establishment method provided by one or more embodiments of this specification.
  • the method in Fig. 2 can be executed by the client in Fig. 1, and specifically can be executed by the SDK set in the client. As shown in Figure 2, the method at least includes the following steps:
  • S202 After detecting a preset service trigger operation, determine whether there is a session identifier locally; where the preset service trigger operation may be a user's touch operation on a payment application installed on the client;
  • the foregoing preset service triggering operation may be a code scanning operation performed by the user through a code scanning function in the payment application, or a user's click operation on the payment control in the payment application;
  • the payment application installed on the client can be a local payment application (ie, a local payment e-wallet), or a payment application (ie, an overseas payment electronic wallet).
  • Wallet a local payment application
  • a payment application ie, an overseas payment electronic wallet.
  • the first attribute information and the second attribute information do not match, it means both parties to the buyer and seller.
  • the corresponding payment server belongs to a different country, it is determined that the payment application installed on the client is an overseas payment application, and the payment between buyers and sellers is a cross-border payment, for example, for consumers to scan merchants through the payment application installed on the client
  • the graphic code of the payment if the payment server corresponding to the payment application installed on the consumer client serves users in the first region (that is, the consumer client is a client used in the first region), and The payment server corresponding to the graphic code for receiving payment provided by the merchant serves users in the second area (that is, the graphic code for the user to receive payment is the graphic code used in the second area), if the first area and the second area Different, it is determined that the payment application installed on the consumer client is an overseas payment application.
  • a trust session needs to be established between the client and the central server, that is, the above step S202 is executed to determine whether there is a session identifie
  • S210 is executed to send a log-in retention request to the central server based on the locally pre-stored log-in retention identifier, so that the central server responds to the log-in retention request and establishes a trusted session with the client.
  • the client after determining that there is no session identifier, it is determined whether the client has a log-in retention identifier locally, and then a corresponding log-in request is sent to the central server according to the judgment result of the presence or absence of the log-in identifier; In the case of identification, the client can request the central server to remain logged in through the keep-login identification, thereby improving the efficiency of the client's secure login.
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the above method further includes: sending a cross-border payment request to the central server, so that the central server responds to the cross-border payment request; wherein, the above-mentioned cross-border payment request
  • the payment request is generated by a client terminal used in the first area performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the target service area of the payment server corresponding to the payment application installed on the client is the first area
  • the client detects the scanning operation for the graphic code used in the second area, based on the information of the graphic code Generate a cross-border payment request, and after the establishment of a trust session between the client and the central server, send the cross-border payment request to the central server;
  • the above-mentioned first area may be a different area from the second area, that is, different areas bounded by different countries, or different areas bounded by different designated geographic areas, for example, the first The region can be a region corresponding to a certain country, and the second region can be a region corresponding to another country, and so on.
  • the payment application installed on the client can be called an overseas payment application, that is, the user uses the client to be served by the payment server corresponding to the payment application installed by the client countries other than the country to make cross-border payments.
  • the above S210 is based on the local pre-stored retention Login ID, which sends a keep-login request to the central server, so that the central server responds to the keep-login request and establishes a trust session with the client, which specifically includes: S2101, based on the locally pre-stored keep-login ID, generate Initiate a keep-login request for keeping-login; S2102, send the aforementioned keep-login request to the central server, so that the central server establishes a trusted session with the client based on the keep-login request.
  • the log-in retention flag is signed, and a log-in retention request carrying the signed retention log-in identifier clientKey is generated, and the log-in retention request is sent to the central server to enable the center service
  • the terminal verifies the legality of the signed keep login ID to ensure that the keep login request has not been tampered with;
  • the log-in ID clientKey before sending the log-in retention request carrying the log-in ID clientKey to the central server, the log-in ID clientKey can be encrypted and signed to generate the corresponding log-in request digest clientKeyDigest, and then the log-in request digest that carries the log-in request is generated.
  • the log-in retention request is sent to the central server, so that the log-in retention clientKey can be transmitted to the central server in the form of a message summary, so as to ensure the transmission security of the log-in retention clientKey.
  • the above S2101 generates a log-in retention request for initiating log-in retention based on the locally pre-stored log-in retention identifier, which specifically includes: S21011, determining the log-in request generation factor, Wherein, the log-in request generation factor includes: at least one of a timestamp and a random factor; S21012, using a preset generation algorithm, according to the locally pre-stored log-in retention identifier and the determined log-in request generation factor to generate a log-in request generation factor for initiating the log-in retention Keep the login request.
  • the log-in request generation factor is the summary generation factor. After the summary generation factor is determined, first use the preset The digest generation algorithm generates a log-in request summary based on the locally pre-stored log-in identifier and the determined summary generation factor, and then generates a log-in request based on the log-in request summary, that is, the log-in request summary carries the log-in request summary;
  • the preset digest generation algorithm is used to perform summary calculations on the clientKey, the timestamp timestamp, and the random factor nonce to obtain the corresponding login.
  • Request digest clientKeyDigest the preset digest generation algorithm can be SHA256 algorithm, MD5 algorithm, or a combination of multiple digest algorithms;
  • the above-mentioned preset digest generation algorithm may be determined according to at least one digest algorithm randomly selected from the set of digest algorithms, wherein the preset digest generation algorithm is a combination of multiple digest algorithms.
  • the order in which the multiple digest algorithms are used is random, so that the preset digest generation algorithm used each time is dynamically changing and unpredictable, avoiding the leakage of the preset digest generation algorithm and reducing the retention of the login ID The issue of transmission security.
  • S502 The client judges whether there is a session identifier sessionId locally.
  • S503 If there is a session identifier sessionId, send a cross-border payment request carrying the session identifier sessionId to the central server, so that the central server responds to the client's cross-border payment request based on the session identifier sessionId and sends to the customer
  • the terminal sends corresponding feedback instructions.
  • S507 The client sends a log-in keeping request carrying the clientKeyDigest to the central server.
  • the central server After receiving the log-in retention request, the central server performs legality verification on the clientKey based on the clientKeyDigest, and generates a legality verification result for the clientKey.
  • S510 The client writes the received sessionId into the local cookie, and establishes a trust session with the central server.
  • the authorized login method can be used to establish a trust session with the central server.
  • the authorized login is sent to the central server Request, so that the central server responds to the authorized login request and establishes a trust session with the client, which specifically includes: S2081, based on the authorization authentication code of the client, send an authorized login request to the central server, so that the central server responds
  • a new session identifier and a maintained login identifier are returned; where the authorization authentication code is theoretically issued by the client by the payment server corresponding to the payment application installed on the client;
  • the storage center server returns the log-in retention identifier; S2083, based on the new session identifier returned by the center server, establishes a trust session with the center server; specifically, the client determines that the log-in retention identifier clientKey does not exist locally Then, send an authorized login request carrying the authorization authentication code authorCode issued by the payment server to the central server; based on the authorized login request, the central server returns a new session identifier and a keep-login identifier to the client;
  • the client After the client receives the new session identifier sessionId and the login-maintaining identifier clientKey returned by the central server, it stores the clientKey so that subsequent requests based on the clientKey maintain login; and write the sessionId to the local cookie to communicate with the central server.
  • the server establishes a trusted session to complete the client's authorized login. Then, the client can send a corresponding cross-border payment request to the central server based on the new sessionId.
  • Step 1 Generate an authorized login request for initiating authorized login based on the authorization authentication code of the client.
  • the authorized login request carries the authorized login code
  • Step 2 Send the above-mentioned authorization login request to the central server, so that the central server requests legality verification from the payment server based on the authorization authentication code, and returns a new one when the legality verification for the authorization authentication code is passed.
  • the session identifier and keep the login ID.
  • the client sends an authorization authentication code acquisition request to the payment server corresponding to the payment application; after receiving the authorization authentication code authorCode returned by the payment server, it sends an authorization login request carrying the authorCode to the central server.
  • the central server After receiving the authorization login request from the client, the central server sends a legality verification request carrying the authorization authentication code authorCode to the payment server corresponding to the client, so that the payment server can verify the legality of the authorCode; , The payment server judges the legitimacy of the authorCode of the client according to the correspondence between the pre-stored user ID userId and the authorCode authorCode.
  • the central server receives the legality verification result of the authorCode from the payment server and the user ID userId corresponding to the client, it returns the new session identifier sessionId and the retained login ID clientKey to the client.
  • the client After the client receives the new session identifier sessionId returned by the central server and the retained login identifier clientKey, it stores the clientKey and writes the sessionId to the local cookie to establish a trusted session with the central server, thereby completing the client's authorized login Then, the client can send a corresponding cross-border payment request to the central server based on the new sessionId, where the authorized login of the client is completed based on the trusted authorization authentication code authorCode, which can prevent subsequent business PRC from being maliciously attacked.
  • the storage center server returns The keeping login identification specifically includes: storing the keeping logging identification returned by the central server into a preset wireless bodyguard in the client; wherein, the anti-attack coefficient of the wireless bodyguard is greater than the preset threshold.
  • the central server in the process of responding to the client's authorization login request by the central server, the central server not only needs to return the new session identifier and the retention login identifier to the client after the authorization verification code authorCode has passed the legality verification. It is necessary to store the corresponding relationship between the user ID userId of the client and the session ID sessionId and keep the login ID clientKey;
  • the following data structure 1 and data structure 2 are used to store the correspondence between the user identifier userId and the session identifier sessionId
  • the following data structure 3 is used to store the correspondence between the user identifier userId and the retention login identifier clientKey, through userId
  • the relationship data with sessionId maintains the validity of sessionId
  • the relationship data between userId and clientKey maintains the validity of clientKey.
  • data structure 1 session main data
  • data structure 2 session idempotent data
  • data structure 3 clientKey relational data
  • S701 The client terminal detects a preset service trigger operation for the payment application.
  • S702 The client judges whether there is a session identifier sessionId locally.
  • S703 If there is a session identifier sessionId, send a cross-border payment request carrying the session identifier sessionId to the central server, so that the central server responds to the client's cross-border payment request based on the session identifier sessionId and sends it to the customer
  • the terminal sends corresponding feedback instructions.
  • S707 The client sends an authorized login request carrying the authorization authentication code authorCode to the central server.
  • S708 The central server requests the payment server to verify the legitimacy of the authorization authentication code authorCode.
  • S710 The central server sends a new session identifier sessionId and a retained login identifier clientKey to the client.
  • S711 The client stores the clientKey returned by the server of the center.
  • S712 The client writes the sessionId returned by the central server into the local cookie, and establishes a trusted session with the central server.
  • S714 The client sends a keep-login request to the central server.
  • the central server responds to the client's log-in keep request and establishes a trust session with the client.
  • the central server first verifies the legality of the session identifier sent by the client. If the legality verification fails, it returns corresponding prompt information to the client to trigger the client to perform the process again.
  • a cross-border business request is sent to the central server based on the local session identifier, so that the central server responds to the cross-border business request and returns to the client
  • the corresponding instruction information specifically includes: S2041, sending a cross-border service request carrying the session identifier to the central server, so that the central server can verify the validity of the session identifier; S2042, receiving the return from the central server Regarding the verification failure result of the session identifier, and continuing to perform the above S206, it is determined whether there is a step of maintaining the login identifier locally.
  • the client after determining that the session identifier sessionID exists in the local cookie, the client initiates an RPC (Remote Procedure Call) to the central server based on the existing sessionID.
  • RPC Remote Procedure Call
  • the central server verifies the legitimacy of the sessionID carried in the request sent by the client, and obtains the legitimacy verification result for the sessionID; specifically, determines the userId and sessionId relationship data corresponding to the client (ie, the above data structure 1 and data Structure 2) According to the relationship data, it is judged whether the sessionID carried in the request sent by the client has expired. If not, it will respond to the client's cross-border business request and execute the corresponding cross-border payment operation, and after the cross-border payment is completed Return the corresponding payment information; if so, it is determined that the validity verification for the sessionID has failed, and the verification failure result for the session identifier is sent to the client.
  • the client in view of the situation that the client has a local retention of the login ID, and the retention of the login ID may also be invalid, the client cannot directly complete the retention of the login at this time, and the client needs to re-use the authorization login method to request a trust session from the central server.
  • the above S2102 sends the above keep log-in request to the central server so that the center server establishes a trust session with the client based on the keep log-on request, which specifically includes: sending the generated log to the central server Keep log-in request, so that the central server will verify the validity of the keep-login ID based on the keep-log-in request; if the central server receives the verification failure result for the keep-login ID, it will serve the center based on the client’s authorization authentication code
  • the terminal sends an authorized login request, so that the central server responds to the authorized login request and establishes a trust session with the client.
  • the client determines that the login request clientKey exists locally, and then generates the corresponding login request digest clientKeyDigest based on the clientKey.
  • the central server sends a log-in retention request carrying the clientKeyDigest; wherein the log-in retention request also carries a digest generation factor, and the digest generation factor includes at least one of a timestamp and a random factor;
  • the central server receives the client's After holding the login request, obtain the pre-stored login identification clientKey corresponding to the client; specifically, determine the userId and clientKey relationship data corresponding to the client (ie, the above data structure 3), and determine the corresponding clientKey according to the relationship data Keep the login ID clientKey;
  • the central server uses the preset summary generation algorithm to generate the login verification summary according to the obtained keep login ID and the summary generation factor carried in the keep login request; where the preset summary generation algorithm and the login request are generated
  • the digest generation algorithm used by the clientKeyDigest is the same.
  • the log-in request that the client sends to the central server also carries There is digest algorithm indication information; according to the digest algorithm indication information, the central server determines the preset digest generation algorithm used to generate the login request digest clientKeyDigest; where the digest algorithm indication information may be information encoded according to a preset encoding rule, The central server decrypts based on the corresponding decoding rules to obtain the decoded digest algorithm indication information, and then according to the decoded digest algorithm indication information, determines the preset digest generation algorithm used to generate the login request digest clientKeyDigest; the central server uses it to determine The preset digest generation algorithm generated is used to generate a login verification digest according to the obtained keep-login identifier and the summary generation factor carried in the keep-login request.
  • the log-in request summary carried in the log-in request is inconsistent with the log-in verification summary generated by the central server, it is determined that the legitimacy verification of the log-in identifier clientKey that exists locally on the client fails; The legality verification of the login ID fails to trigger the client to re-send the authorization login request to the central server.
  • the process of the client re-requesting the central server to authorize login is the same as the process of authorizing login performed in the case where the client does not have a locally maintained login ID, and will not be repeated here.
  • the central server will directly return the new session identifier to the client if the validity verification of the login ID is maintained, indicating that the client can establish a session with the central server by keeping the login method. Based on this, After sending the generated keep-login request to the central server, so that the central server verifies the validity of the keep-login identifier based on the keep-login request, it also includes: if the central server returns a new session identifier, then Based on the new session identifier, a trust session is established with the central server; wherein, the above new session identifier is sent by the central server to the client when the verification of the validity of the maintained login identifier is passed.
  • the central server determines that the validity verification result of the log-in identifier is passed, and returns a new session identifier sessionId to the client.
  • the login request summary is generated based on the login request summary first, and then the login request summary is generated based on the login request summary, if the login request summary carried in the login request is kept consistent with the login verification summary generated by the central server, Then the central server determines that the validity verification result of the clientKey carried in the login request is passed, and returns a new session identifier sessionId to the client.
  • the central server determines that the log-in identifier clientKey has passed the verification, it not only needs to return the new session identifier sessionId to the client, but also needs to store the client's user ID and userId and The corresponding relationship between the session identifier sessionId, wherein the relationship data between the user identifier userId and the clientKey can be stored in the above-mentioned data structure 3.
  • the client writes the new sessionId returned by the central server into the local cookie, and establishes a trusted session with the central server, thereby completing the client's keeping login. Then, the client can send the corresponding cross-border to the central server based on the new sessionId Payment request, where the client’s keep logging on is completed based on the log on request digest clientKeyDigest corresponding to the keep logging identifier clientKey, which can prevent subsequent business PRC from being maliciously attacked.
  • the session establishment method after detecting a preset service trigger operation for a payment application installed on a client, it is determined whether there is a session identifier locally. If the session identifier does not exist locally on the client, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server to the client's authorized log-in request. If the client has a log-in keeping identity locally, based on the log-on keeping identity, a log-on keeping request is sent to the central server, so that the central server responds to the log-on request and establishes a trusted session with the client.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • FIG. 9 is a session provided by one or more embodiments of this specification.
  • S902 Receive a log-in retention request from the client, where the log-in retention request carries a locally pre-stored log-in retention identifier, and the log-in retention identifier is sent by the central server for the client's authorized log-in request.
  • the client sends a log-on keeping request to the central server when it determines that there is a log-on keeping identifier locally.
  • S904 In response to the received log-in keeping request, establish a trusted session with the client based on the log-in keeping identifier.
  • the specific implementation process of the central server establishing a trusted session with the client based on the keeping login identifier can refer to the relevant steps in the above-mentioned session establishment method executed by the client, which will not be repeated here.
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the above method further includes: receiving a cross-border payment request sent by the client, and responding to the cross-border payment request; wherein, the cross-border payment request is The client used in the first area is generated by performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the target service area of the payment server corresponding to the payment application installed on the client is the first area
  • the client detects the scanning operation for the graphic code used in the second area, based on the information of the graphic code Generate a cross-border payment request, and after the establishment of a trust session between the client and the central server, send the cross-border payment request to the central server;
  • the above-mentioned first area may be a different area from the second area, that is, Different regions bounded by different countries, or different regions bounded by different designated geographic regions.
  • the first region can be the region corresponding to a certain country
  • the second region can be another country. Corresponding area, etc.
  • the payment application installed on the client can be called an overseas payment application, that is, the user uses the client to be served by the payment server corresponding to the payment application installed by the client countries other than the country to make cross-border payments.
  • the above-mentioned keep-login request is generated based on the keep-login identifier; correspondingly, the above S904, in response to the received keep-login request, establishes a trust session with the client based on the keep-login identifier, which specifically includes: The legality verification of the maintained login identifier is performed to obtain a corresponding legality verification result; based on the legality verification result for the maintained login identifier, a trust session with the client is established.
  • the client can first encrypt and sign the keep login identification clientKey, generate the corresponding login request digest clientKeyDigest, then generate the keep login request carrying the login request digest, and then send the keep login request to the central server;
  • the central server verifies the validity of the login ID, and obtains the corresponding legality verification result, which can be transmitted to the central server in the form of a message digest. Keep the login ID clientKey, so as to ensure that the transmission security of the login ID clientKey is maintained.
  • the above log-in retention request also carries a log-in request generation factor; correspondingly, the legality verification of the log-in retention flag is performed to obtain the corresponding legality verification result, which specifically includes: obtaining the log-in retention flag corresponding to the client ; Use a preset generation algorithm to generate login verification information for verifying the log-in request based on the log-in retention identifier and the log-in request generation factor; if the log-in retention request matches the log-in verification information, it is determined The verification result of the validity of the maintained login ID is passed.
  • the log-in request generation factor is the digest generation factor.
  • the digest generation factor For the process of validating the legality of the log-in ID, you can Using the preset digest generation algorithm, based on the digest generation factor carried in the hold login request and the hold login identification corresponding to the client pre-stored on the central server, a login verification summary for verifying the hold login request is generated; then the login verification is judged Whether the digest is consistent with the login request digest sent by the client, if they are consistent, it is determined that the legality verification result for the maintained login ID is passed.
  • the method further includes: receiving an authorized login request from the client, where the authorized login request is sent by the client to determine that there is no local log-in identifier, and the authorized login request carries the authorization authentication code of the client, and The authorization authentication code is issued by the payment server corresponding to the payment application installed on the client for the client; in response to the authorization login request, a new authentication code is returned to the client based on the authorization authentication code.
  • the session identifier and the keep-login identity of the client so that the client stores the keep-login identity and establishes a trust session with the central server based on the new session identifier.
  • the foregoing returning a new session identifier and a keep-login identifier to the client based on the authorization authentication code specifically includes: requesting a payment server corresponding to the payment application triggered by the client based on the authorization authentication code Authorization authentication code legality verification; if a legality verification pass result for the authorization authentication code is received, a new session identifier and a keep-login identifier are returned to the client.
  • the central server determines that the authorization authentication code authorCode has passed the legality verification, it not only needs to return the new session identifier and the keep login ID to the client, but also needs to store the client's user ID userId and session identifier sessionId and keep the login. Identify the corresponding relationship between the clientKey, based on this, after returning a new session identifier and a keep-login identifier to the client based on the authorization authentication code, the method further includes: storing the user identifier of the client and the new The corresponding relationship between the session identifier and the maintained login identifier.
  • the client in view of the failure of the validity verification of the maintained login ID, the client needs to re-send the authorization login request to the central server. Based on this, the above-mentioned establishment of the authentication result is based on the validity verification result for the maintained login ID.
  • the trust session between the clients specifically includes: if the legality verification result indicates that the verification fails, sending the legality verification failure result to the client, so that the client is based on the result obtained from the corresponding payment server.
  • the authorization authentication code sends an authorization login request to the central server; in response to the authorization login request, a trust session with the client is established based on the authorization authentication code.
  • the central server directly returns a new session ID to the client, so that the client can establish a trusted session.
  • the said The legality verification result, establishing a trust session with the client specifically includes:
  • a new session identifier is sent to the client, so that the client establishes a trust session with the central server based on the new session identifier.
  • the session establishment method in one or more embodiments of the present specification receives a keep-login request from a client, wherein the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is a central server's authorized login request for the client Sent.
  • the keep-login identifier is a central server's authorized login request for the client Sent.
  • a trusted session with the client is established based on the log-in retention identifier.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • Figure 10 provides one or more embodiments of this specification.
  • the method in FIG. 10 can be executed by the client in FIG. 1, specifically, it can be executed by the SDK set in the client. As shown in FIG. 10, the method includes at least the following steps.
  • S1002 After detecting a preset service trigger operation for the payment application installed on the client, it is determined whether there is a session identifier locally.
  • S1004 If there is no session identifier, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server to the client's authorized log-in request.
  • S1006 If there is a log-in retention identifier, based on the log-in retention identifier, send a log-in retention request to the central server, so that the central server responds to the log-in retention request and establishes a trusted session with the client.
  • S1008 Send a cross-border payment request to the central server, so that the central server responds to the cross-border payment request and executes a corresponding cross-border payment operation.
  • the above-mentioned cross-border payment request is generated by a client used in the first area performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the central server for the process of establishing a trust session between the client and the central server, sends the corresponding session to the client at the same time when the client requests authorization to log in.
  • Identifier and keep-login ID so that subsequent clients can directly request to keep logged in based on the keep-login ID, so that there is no need to perform the complicated interactive process of authorized login during the valid period of the keep-login ID, which reduces the frequency of authorized login calls and simplifies the client
  • the interactive steps of establishing a trust session with the central server can not only ensure that the client can safely log in to the SAAS service of the central server, but also improve the security login efficiency of the client, thereby improving the response of the central server to the client's cross-border payment request efficiency.
  • Figure 11 provides one or more embodiments of this specification.
  • S1102. Receive a keep-login request from the client, where the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is sent by the central server for the client's authorized log-in request.
  • S1106 Receive a cross-border payment request sent by the client, and execute a corresponding cross-border payment operation.
  • the aforementioned cross-border payment request is generated by a client terminal used in the first area performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the central server for the process of establishing a trust session between the client and the central server, sends the corresponding session to the client at the same time when the client requests authorization to log in.
  • Identifier and keep-login ID so that subsequent clients can directly request to keep logged in based on the keep-login ID, so that there is no need to perform the complicated interactive process of authorized login during the valid period of the keep-login ID, which reduces the frequency of authorized login calls and simplifies the client
  • the interactive steps of establishing a trust session with the central server can not only ensure that the client can safely log in to the SAAS service of the central server, but also improve the security login efficiency of the client, thereby improving the response of the central server to the client's cross-border payment request efficiency.
  • one or more embodiments of this specification also provide a session establishment device, which is set on the client in FIG. 1, and FIG. 12 shows A schematic diagram of the module composition of a session establishment device provided in one or more embodiments of this specification. The device is used to execute the session establishment method described in FIG. 2 to FIG. 8. As shown in FIG.
  • the device includes: a first judgment module 1201, After detecting a preset service trigger operation for the payment application installed on the client, it determines whether there is a session identifier locally; the second determination module 1202, if there is no session identifier, determines whether there is a hold locally Login identifier, wherein the maintained login identifier is sent by the central server in response to the client’s authorized login request; the session establishment module 1203, if there is a maintained login identifier, it will send a notification to all users based on the maintained login identifier.
  • the central server sends a log-in retention request, so that the central server responds to the log-in retention request and establishes a trusted session with the client.
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the above-mentioned apparatus further includes: a cross-border request sending module, which: sends a cross-border payment request to the central server, so that the central server responds to the cross-border payment request; wherein, the cross-border payment request
  • the external payment request is generated by the client used in the first area performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the above-mentioned session establishment module 1203 generates a keep-login request for initiating keep-login based on the keep-login identifier; sends the keep-login request to the central server so that the central server is based on The keep-login request establishes a trusted session with the client.
  • the above-mentioned session establishment module 1203 determines a log-in request generation factor, wherein the log-in request generation factor includes at least one of a timestamp and a random factor; a preset generation algorithm is used, based on the keep-login identification and The log-in request generation factor generates a log-in retention request for initiating log-in retention.
  • the above-mentioned session establishment module 1203 generates an authorized login request for initiating an authorized login based on the authorization authentication code of the client; sends the authorized login request to the central server to enable the central service
  • the terminal requests legality verification from the payment server based on the authorization authentication code, and returns a new session identifier and a keep-login identifier when the legality verification for the authorization authentication code is passed.
  • the above-mentioned session establishment module 1203 sends the log-in keeping request to the central server, so that the central server can verify the legality of the log-in keeping identifier based on the log-in keeping request;
  • the central server fails to verify the result of the retention of the login identifier, based on the authorization authentication code of the client, an authorized login request is sent to the central server, so that the central server responds to the authorization Log in to request and establish a trust session with the client.
  • the session establishment device determines whether there is a session identifier locally after detecting a preset service trigger operation for the payment application installed on the client. If the session identifier does not exist locally on the client, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server to the client's authorized log-in request. If the client has a log-in keeping identity locally, based on the log-on keeping identity, a log-on keeping request is sent to the central server, so that the central server responds to the log-on keep request and establishes a trusted session with the client.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • one or more embodiments of this specification also provide a session establishment device, which is set at the central server in FIG. 1, and FIG. 13 is the specification.
  • a schematic diagram of the module composition of a session establishment apparatus provided by one or more embodiments. The apparatus is used to execute the session establishment method described in FIG. 9. As shown in FIG.
  • the apparatus includes: a keep-login request receiving module 1301, which receives the The client's keep-login request, wherein the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is sent by the central server for the client's authorized log-in request; a trusted session establishment module 1302 In response to the log-in keep request, it establishes a trusted session with the client based on the log-in keep identifier.
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the above-mentioned apparatus further includes: a cross-border request receiving module, which: receives a cross-border payment request sent by the client, and responds to the cross-border payment request; wherein, the cross-border payment request is in the first
  • the client used in one area is generated by performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the above-mentioned trust session establishment module 1302 which verifies the legality of the maintained login ID to obtain a corresponding legality verification result; based on the legality verification result for the maintained login ID, establishes a connection with the Trust session between clients.
  • the log-in retention request also carries a log-in request generation factor; correspondingly, the above-mentioned trust session establishment module 1302 obtains the log-in retention identifier corresponding to the client; using a preset generation algorithm, according to the retention The login identifier and the login request generation factor are used to generate login verification information for verifying the log-in retention request; if the log-in retention request matches the log-in verification information, the validity of the log-in retention flag is determined The verification result passed.
  • the above-mentioned apparatus further includes: an authorized login request receiving module, which receives an authorized login request from the client, wherein the authorized login request is sent by the client to determine that there is no local log-in identifier, and The authorization login request carries an authorization authentication code of the client, and the authorization authentication code is issued for the client by the payment server corresponding to the payment application installed on the client;
  • the aforementioned trusted session establishment module 1302 which responds to the authorized login request, returns a new session identifier and a retained login identifier to the client based on the authorized authentication code, so that the client stores the Keep the login identifier, and establish a trust session with the central server based on the new session identifier.
  • the above-mentioned trust session establishment module 1302 based on the authorization authentication code, requests the payment server corresponding to the payment application triggered by the client to verify the validity of the authorization authentication code; If the legality verification of the authentication code passes the result, the new session identifier and the keep-login identifier are returned to the client.
  • the above-mentioned trusted session establishment module 1302 stores the correspondence between the user ID of the client and the new session ID and the keep-login ID.
  • the above-mentioned trust session establishment module 1302 if the legality verification result indicates that the verification fails, it sends the legality verification failure result to the client, so that the client can obtain the result from the corresponding payment server based on Send an authorized login request to the central server by the authorization authentication code; in response to the authorized login request, establish a trust session with the client based on the authorization authentication code.
  • the above-mentioned trusted session establishment module 1302 sends a new session identifier to the client if the legality verification result indicates that the verification is passed, so that the client is based on the new session identifier Establish a trust session with the central server.
  • the session establishment device in one or more embodiments of the present specification receives a keep-login request from a client, wherein the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is a central server's authorized login request for the client Sent.
  • the keep-login identifier is a central server's authorized login request for the client Sent.
  • a trusted session with the client is established based on the log-in retention identifier.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • one or more embodiments of this specification also provide a cross-border payment device.
  • the device is set at the client in FIG. 1, and the device is used for Performing the cross-border payment method described in FIG.
  • the device includes: a first determining module, which determines whether there is a session identifier locally after detecting a preset service trigger operation for the payment application installed on the client;
  • the second judgment module if there is no session identifier, judge whether there is a log-in retention identifier locally, wherein the log-in retention identifier is sent by the central server for the authorization log-in request of the client;
  • the session establishment module If there is a log-in retention identifier, based on the log-in retention identifier, a log-in retention request is sent to the central server, so that the central server responds to the log-in retention request and establishes a connection with the client Trust session;
  • payment request sending module which sends a cross-border payment request to the central server, so that the central server responds to the cross-border payment request and executes the corresponding cross-border payment operation.
  • the aforementioned payment request sending module generates a cross-border payment request based on the information of the graphic code scanned by the client, and sends the cross-border payment request to the central server; wherein, the cross-border payment request is The external payment request is generated by the client used in the first area performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the central server for the process of establishing a trust session between the client and the central server, sends the corresponding session to the client at the same time when the client requests authorization to log in.
  • Identifier and keep-login ID so that subsequent clients can directly request to keep logged in based on the keep-login ID, so that there is no need to perform the complicated interactive process of authorized login during the valid period of the keep-login ID, which reduces the frequency of authorized login calls and simplifies the client
  • the interactive steps of establishing a trust session with the central server can not only ensure that the client can safely log in to the SAAS service of the central server, but also improve the security login efficiency of the client, thereby improving the response of the central server to the client's cross-border payment request efficiency.
  • one or more embodiments of this specification also provide a cross-border payment device, which is set on the central server in FIG. In executing the cross-border payment method described in FIG.
  • the device includes: a keep-login request receiving module that receives a keep-login request from the client, wherein the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login request
  • the login identifier is sent by the central server for the authorized login request of the client; the trust session establishment module, which responds to the log-in retention request, establishes trust with the client based on the log-in retention identifier Session; a cross-border payment processing module, which receives the cross-border payment request sent by the client, and executes the corresponding cross-border payment operation.
  • the above-mentioned cross-border payment processing module receives the cross-border payment request generated by the client based on the information of the graphic code scanned by the client; wherein, the cross-border payment request is used in the first area.
  • the client is generated by performing a code scanning operation on the graphic code used in the second area, and the first area is different from the second area.
  • the central server for the process of establishing a trust session between the client and the central server, sends the corresponding session to the client at the same time when the client requests authorization to log in.
  • Identifier and keep-login ID so that subsequent clients can directly request to keep logged in based on the keep-login ID, so that there is no need to perform the complicated interactive process of authorized login during the valid period of the keep-login ID, which reduces the frequency of authorized login calls and simplifies the client
  • the interactive steps of establishing a trust session with the central server can not only ensure that the client can safely log in to the SAAS service of the central server, but also improve the security login efficiency of the client, thereby improving the response of the central server to the client's cross-border payment request efficiency.
  • one or more embodiments of this specification also provide a session establishment system, which includes: the client in FIG. 1 And the central server; wherein, the client includes the session establishment device shown in FIG. 12, and the central server includes the session establishment device shown in FIG. 13.
  • the client detects the user's preset service triggering operation for the payment application, it determines whether the session identifier sessionId exists locally; if the client determines that the session identifier sessionId exists locally, it sends the session identifier to the central server.
  • the cross-border payment request with the identifier sessionId so that the central server responds to the client's cross-border payment request based on the session identifier sessionId and sends corresponding feedback instructions to the client; if the client determines that the session identifier sessionId does not exist locally, Then it is judged whether there is a clientKey that keeps the login ID locally.
  • the client sends a login request to the central server based on the clientKey; the central server responds to the client's login request to keep the login request carried Keep the login identifier clientKey for legality verification; if the central server determines that the clientKey has passed the legality verification, it returns a new session identifier sessionId to the client; the client receives the new session identifier sessionId returned by the central server Establish a trusted session with the central server based on the sessionId.
  • the client sends an authorized login request to the central server based on the authorization authentication code issued by the payment server corresponding to the payment application; the central server responds to the client's authorized login request , Request the payment server corresponding to the payment application to verify the validity of the authorization verification code; if the central server receives the result of the verification of the authorization verification code, it returns a new session identifier sessionId and Keep the login ID clientKey; after the client receives the new session ID sessionId and keep the login ID clientKey, it establishes a trust session with the central server based on the sessionId, and stores the clientKey, where subsequent clients can send to the center based on the clientKey
  • the server requests to keep logged in, so that a trust session is established between the client and the central server, that is, a trust session between the SDK of the client and the SAAS service of the central server is established.
  • the central server for the process of establishing a trusted session between the client and the central server, sends the corresponding session identifier to the client at the same time when the client requests authorization to log in. And keep the login ID, so that the subsequent client directly requests to keep the login based on the keep the login ID, so that there is no need to execute the complicated interactive process of authorized login during the valid period of the keep login ID, which reduces the frequency of authorized login calls and simplifies the client and
  • the interactive steps of establishing a trusted session between the central server can not only ensure that the client can safely log in to the SAAS service of the central server, but also can improve the efficiency of the client's secure login.
  • one or more embodiments of this specification also provide a cross-border payment system, which includes: the client and the client in Figure 1 The central server; wherein, the client includes a device corresponding to the cross-border payment method shown in FIG. 10, and the center server includes a device corresponding to the cross-border payment method shown in FIG. 11.
  • the client detects the user's preset service triggering operation for the payment application, it determines whether the session identifier sessionId exists locally; if the client determines that the session identifier sessionId exists locally, it sends the session identifier to the central server.
  • the cross-border payment request with the identifier sessionId so that the central server responds to the client's cross-border payment request based on the session identifier sessionId and sends corresponding feedback instructions to the client; if the client determines that the session identifier sessionId does not exist locally, Then it is judged whether there is a clientKey that keeps the login ID locally.
  • the client sends a login request to the central server based on the clientKey; the central server responds to the client's login request to keep the login request carried Keep the login identifier clientKey for legality verification; if the central server determines that the clientKey has passed the legality verification, it returns a new session identifier sessionId to the client; the client receives the new session identifier sessionId returned by the central server Establish a trusted session with the central server based on the sessionId.
  • the client sends an authorized login request to the central server based on the authorization authentication code issued by the payment server corresponding to the payment application; the central server responds to the client's authorized login request , Request the payment server corresponding to the payment application to verify the validity of the authorization verification code; if the central server receives the result of the verification of the authorization verification code, it returns a new session identifier sessionId and Keep the login ID clientKey; after the client receives the new session ID sessionId and keep the login ID clientKey, it establishes a trust session with the central server based on the sessionId, and stores the clientKey, where subsequent clients can send to the center based on the clientKey
  • the server requests to remain logged in to establish a trust session between the client and the central server, that is, to establish a trust session between the client’s SDK and the SAAS service of the central server; the client sends a cross-border payment request to the central server to Make the central server respond to the cross-border payment request and
  • the central server for the process of establishing a trust session between the client and the central server, sends the corresponding session to the client at the same time when the client requests authorization to log in.
  • Identifier and keep-login ID so that subsequent clients can directly request to keep logged in based on the keep-login ID, so that there is no need to perform the complicated interactive process of authorized login during the valid period of the keep-login ID, which reduces the frequency of authorized login calls and simplifies the client
  • the interactive steps of establishing a trust session with the central server can not only ensure that the client can safely log in to the SAAS service of the central server, but also improve the security login efficiency of the client, thereby improving the response of the central server to the client's cross-border payment request efficiency.
  • one or more embodiments of this specification also provide a session establishment device, which is used to execute the above session establishment method, such as Shown in Figure 14.
  • the session establishment device may have relatively large differences due to different configurations or performances, and may include one or more processors 1401 and a memory 1402, and the memory 1402 may store one or more storage applications or data. Among them, the memory 1402 may be short-term storage or persistent storage.
  • the application program stored in the memory 1402 may include one or more modules (not shown in the figure), and each module may include a series of computer-executable instructions for the session establishment device.
  • the processor 1401 may be configured to communicate with the memory 1402, and execute a series of computer-executable instructions in the memory 1402 on the session establishment device.
  • the session establishment device may also include one or more power supplies 1403, one or more wired or wireless network interfaces 1404, one or more input and output interfaces 1405, one or more keyboards 1406, and so on.
  • the session establishment device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each Each module may include a series of computer-executable instructions in the session establishment device, and the one or more programs configured to be executed by one or more processors include computer-executable instructions for performing the following: After the preset service trigger operation of the payment application installed on the client, it is determined whether there is a session identifier locally; if there is no session identifier, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is the The central server sends a login request for the client’s authorization; if there is a log-in retention identifier, based on the log-in retention identifier, a log-in retention request is sent to the central server so that the central server responds to the request. Said maintaining the login request and establishing a trust session with the client.
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the method further includes: sending a cross-border payment request to the central server, So that the central server responds to the cross-border payment request; wherein, the cross-border payment request is that the client used in the first area performs a code scanning operation on the graphic code used in the second area Generated, the first area is different from the second area.
  • the log-in retention request is sent to the central server based on the log-in retention identifier, so that the central server responds to the log-in retention request and establishes a connection with the central server.
  • the trust session between the clients includes: generating a keep logging request for initiating keep logging based on the keep logging identifier; sending the keep logging request to the central server so that the central server Establishing a trusted session with the client based on the keep-login request.
  • the generating a log-in retention request for initiating log-in retention based on the log-in retention identifier includes: determining a log-in request generation factor, wherein the log-in request generation factor includes : At least one of a timestamp and a random factor; using a preset generation algorithm to generate a log-in retention request for initiating log-in retention according to the log-in retention identifier and the log-in request generation factor.
  • the computer executable instruction when executed, after judging whether there is a log-in retention identifier locally, it further includes: if the log-in retention identifier does not exist, sending to the central server based on the authorization authentication code of the client Authorize the login request, so that the central server responds to the authorized login request and returns a new session identifier and a keep-login identifier; wherein, the authorization authentication code is that the payment server corresponding to the payment application is the Issued by the client; storing the keeping login identification, and establishing a trust session with the central server based on the new session identifier.
  • the authorization authentication code based on the client sends an authorization login request to the central server, so that the central server responds to the authorized login request and Returning the new session identifier and keeping the login identifier includes: generating an authorized login request for initiating authorized login based on the authorization authentication code of the client; sending the authorized login request to the central server so that the The central server requests legality verification from the payment server based on the authorization authentication code, and returns a new session identifier and a keep-login identifier when the legality verification for the authorization authentication code is passed.
  • the computer-executable instructions when executed, after judging whether there is a session identifier locally, it further includes: if there is a session identifier, sending a cross-border message carrying the session identifier to the central server Service request, so that the central server can verify the validity of the session identifier; if the central server receives a verification failure result for the session identifier, it executes to determine whether there is a local log-in identifier step.
  • the log-in request is sent to the central server, so that the central server establishes a connection with the client based on the log-in request.
  • the trust session includes: sending the log-in keeping request to the central server, so that the central server can verify the legality of the log-in keeping identifier based on the log-in keeping request; if the central server is received For the verification failure result of the maintained login ID, based on the authorization authentication code of the client, an authorized login request is sent to the central server, so that the central server responds to the authorized login request and establishes a connection with the central server. Describes the trust session between the clients.
  • the log-in keeping request is sent to the central server, so that the central server can verify the legality of the log-in keeping flag based on the log-in keeping request.
  • the central server further includes: if a new session identifier returned by the central server is received, establishing a trust session with the central server based on the new session identifier; wherein, the new session identifier The symbol is sent to the client when the validity verification of the keeping login identifier is passed.
  • the session establishment device determines whether there is a session identifier locally after detecting a preset service trigger operation for the payment application installed on the client. If the session identifier does not exist locally on the client, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server to the client's authorized log-in request. If the client has a log-in keeping identity locally, based on the log-on keeping identity, a log-on keeping request is sent to the central server, so that the central server responds to the log-on keep request and establishes a trusted session with the client.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • the session establishment device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and the one or more programs may include one or more modules, and Each module may include a series of computer-executable instructions in the session establishment device, and the one or more programs configured to be executed by one or more processors include computer-executable instructions for performing the following: receiving the client Log-in request of the client terminal, wherein the log-in retention request carries a locally pre-stored log-in retention identifier, and the log-in retention identifier is sent by the central server for an authorized login request of the client; in response to the log-in retention request Request to establish a trusted session with the client based on the keep-login identifier.
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the method further includes: receiving a cross-border payment request sent by the client, And respond to the cross-border payment request; wherein, the cross-border payment request is generated by the client used in the first area performing a code scanning operation on the graphic code used in the second area, the The first area is different from the second area.
  • the establishment of a trust session with the client based on the keep-login identifier in response to the keep-login request includes: performing the keep-login identifier The legality verification obtains a corresponding legality verification result; based on the legality verification result for the maintained login ID, a trust session with the client is established.
  • the log-in retention request when the computer-executable instructions are executed, the log-in retention request also carries a log-in request generation factor; the log-in retention request is based on the legality verification of the log-in retention flag to obtain the corresponding legitimacy
  • the verification result includes: obtaining a log-in retention identifier corresponding to the client terminal; using a preset generation algorithm to generate log-in verification information for verifying the log-in retention request based on the log-in retention identifier and the log-in request generation factor If the log-in keeping request matches the log-in verification information, it is determined that the legality verification result of the log-in keeping flag is passed.
  • the computer-executable instructions further include the following computer-executable instructions: receiving an authorized login request from the client, where the authorized login request is the client determining that there is no local hold The login ID is sent, and the authorization login request carries the authorization authentication code of the client, and the authorization authentication code is issued by the payment server corresponding to the payment application installed on the client for the client
  • the authorized login request based on the authorization authentication code, return a new session identifier and a maintained login identifier to the client, so that the client stores the maintained login identifier and is based on the new
  • the session identifier establishes a trust session with the central server.
  • the returning a new session identifier and a keep-login identifier to the client based on the authorization authentication code includes: based on the authorization authentication code, sending a message to the client
  • the payment server corresponding to the payment application triggered by the client requests the validity verification of the authorization authentication code; if the validity verification result for the authorization authentication code is received, it returns a new session identifier and hold to the client Login ID.
  • the computer-executable instruction when executed, after returning a new session identifier and a keep-login identifier to the client based on the authorization authentication code, it further includes: storing the user identifier of the client and the The corresponding relationship between the new session identifier and the maintained login identifier.
  • the establishment of a trust session with the client based on the legality verification result for the maintained login identifier includes: if the legality verification is If the result indicates that the verification fails, the legality verification failure result is sent to the client, so that the client sends an authorization login request to the central server based on the authorization authentication code obtained from the corresponding payment server; The authorized login request establishes a trust session with the client based on the authorized authentication code.
  • the establishment of a trust session with the client based on the legality verification result for the maintained login identifier includes: if the legality verification is If the result indicates that the verification is passed, a new session identifier is sent to the client, so that the client establishes a trust session with the central server based on the new session identifier.
  • the session establishment device in one or more embodiments of this specification receives a keep-login request from a client, where the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is a central server's authorized login request for the client Sent.
  • the keep-login identifier is a central server's authorized login request for the client Sent.
  • a trusted session with the client is established based on the log-in retention identifier.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • one or more embodiments of this specification also provide a storage medium for storing computer-executable instructions, a specific implementation
  • the storage medium may be a U disk, an optical disk, a hard disk, etc.
  • the computer executable instructions stored in the storage medium are executed by the processor, the following process can be realized: After the operation is triggered by the preset service, it is determined whether there is a session identifier locally; if there is no session identifier, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is the central server's target for the client Authorized log-in request sent; if there is a log-in retention identifier, based on the log-in retention identifier, a log-in retention request is sent to the central server, so that the central server responds to the log-in retention request and establishes a connection with the central server. Describes the trust session
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the method further includes: serving the central server The client sends a cross-border payment request, so that the central server responds to the cross-border payment request; wherein, the cross-border payment request is that the client pair used in the first region uses the client pair in the second region.
  • the graphic code of is generated by performing a code scanning operation, and the first area is different from the second area.
  • the log-in retention request is sent to the central server based on the log-in retention identifier, so that the central server end responds to the central server.
  • the maintaining login request and establishing a trusted session with the client includes: generating a maintaining login request for initiating the maintaining login based on the maintaining login identifier; sending the maintaining login request to the central server, So that the central server establishes a trusted session with the client based on the keep-login request.
  • generating a log-in retention request for initiating log-in retention based on the log-in retention identifier includes: determining a log-in request generation factor, where: The log-in request generation factor includes at least one of a timestamp and a random factor; a preset generation algorithm is used to generate a log-in retention request for initiating log-in retention according to the log-in retention identifier and the log-in request generation factor.
  • the method further includes: if the log-in retention identifier does not exist, based on the authorization authentication code of the client, Send an authorized login request to the central server, so that the central server responds to the authorized login request and returns a new session identifier and a keep-login identifier; wherein, the authorization authentication code corresponds to the payment application
  • the payment server is issued by the client; stores the keep-login identifier, and establishes a trust session with the central server based on the new session identifier.
  • the authorization authentication code based on the client sends an authorization login request to the central server, so that the central server responds Returning a new session identifier and a keep-login identifier to the authorized login request includes: generating an authorized login request for initiating authorized login based on the authorization authentication code of the client; and sending the authorization to the central server A login request, so that the central server requests legality verification from the payment server based on the authorization authentication code, and returns a new session identifier and a new session identifier when the legality verification for the authorization authentication code is passed. Keep the login ID.
  • the computer-executable instructions stored in the storage medium when executed by the processor, after judging whether there is a session identifier locally, it further includes: if there is a session identifier, sending the carrying information to the central server.
  • the cross-border service request of the session identifier so that the central server can verify the validity of the session identifier; if the central server receives a verification failure result for the session identifier, then execute the judgment Whether there is a step to maintain the login ID locally.
  • the log-in request is sent to the central server, so that the central server establishes a log-in request based on the log-in request.
  • the trust session between the clients includes: sending the log-in keeping request to the central server, so that the central server can verify the legality of the log-in keeping identifier based on the log-in keeping request; if After receiving the verification failure result of the central server for the keeping login identifier, based on the authorization authentication code of the client, an authorized login request is sent to the central server, so that the central server responds to the Authorize the login request and establish a trust session with the client.
  • the method further includes: if a new session identifier is received from the central server, establishing a trust session with the central server based on the new session identifier; wherein , The new session identifier is sent to the client when the legality verification of the maintained login identifier is passed.
  • the processor After detecting a preset service trigger operation for the payment application installed on the client, it is determined whether there is a session identifier locally symbol. If the session identifier does not exist locally on the client, it is determined whether there is a log-in retention identifier locally, where the log-in retention identifier is sent by the central server to the client's authorized log-in request. If the client has a log-in keeping identity locally, based on the log-on keeping identity, a log-on keeping request is sent to the central server, so that the central server responds to the log-on keep request and establishes a trusted session with the client.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • the storage medium may be a U disk, an optical disk, a hard disk, etc.
  • the computer executable instructions stored in the storage medium can implement the following process when being executed by the processor: receiving the client's keep login Request, wherein the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login identifier is sent by the central server for an authorized log-in request of the client; in response to the keep-login request, based on The keeping login identifier establishes a trust session with the client.
  • the central server for the process of establishing a trusted session between the client and the central server, during the client request authorization login phase, the central server sends the corresponding session identifier to the client and keeps the login at the same time Logo, so that subsequent clients directly request to keep logged in based on the keep logon logo, so that there is no need to perform the complex interactive process of authorized logon during the valid period of the keep logon logo, which reduces the frequency of authorized logon calls, thereby simplifying the communication between the client and the central server.
  • the interactive steps of establishing a trust session between them can not only ensure that the client can safely log in to the SAAS service of the center server, but also improve the efficiency of the client's secure login.
  • the method further includes: receiving the client A cross-border payment request sent in response to the cross-border payment request; wherein the cross-border payment request is performed by the client used in the first area to scan the graphic code used in the second area As a result of the operation, the first area is different from the second area.
  • the establishment of a trusted session with the client in response to the log-in retention request based on the log-in retention identifier includes: Perform legality verification on the maintained login ID to obtain a corresponding legality verification result; based on the legality verification result for the maintained login ID, establish a trust session with the client.
  • the log-in retention request when the computer-executable instructions stored in the storage medium are executed by the processor, the log-in retention request also carries a log-in request generation factor; the log-in retention identifier performs legality verification to obtain a corresponding legality verification result , Including: obtaining a log-in retention identifier corresponding to the client; using a preset generation algorithm to generate log-in verification information according to the log-in retention identifier and the log-in request generation factor; if the log-in retention request corresponds to the log-in If the verification information matches, it is determined that the legality verification result for the maintained login ID is passed.
  • the following process is also implemented: receiving an authorized login request from the client, where the authorized login request is the client determining that the client does not exist locally Keep the login ID sent, and the authorization login request carries the authorization authentication code of the client, the authorization authentication code is issued by the client by the payment server corresponding to the payment application installed on the client
  • the authorization authentication code is issued by the client by the payment server corresponding to the payment application installed on the client
  • return a new session identifier and a maintained login identifier to the client, so that the client stores the maintained login identifier and is based on the new
  • the session identifier of Establishes a trusted session with the central server In response to the authorized login request, based on the authorization authentication code, return a new session identifier and a maintained login identifier to the client, so that the client stores the maintained login identifier and is based on the new The session identifier of Establishes a trusted session with the central server.
  • the returning a new session identifier and a retention login identifier to the client based on the authorization authentication code includes: based on the authorization The authentication code, which requests the payment server corresponding to the payment application triggered by the client to verify the validity of the authorization authentication code; if a legality verification result for the authorization authentication code is received, return to the client New session identifier and keep login identifier.
  • the method further includes: storing the The corresponding relationship between the user ID of the client and the new session ID and the keep-login ID.
  • the establishment of a trust session with the client based on the legality verification result for the maintained login identifier includes : If the legality verification result indicates that the verification has failed, the legality verification failure result is sent to the client, so that the client sends to the central server based on the authorization authentication code obtained from the corresponding payment server Authorized login request; in response to the authorized login request, establish a trust session with the client based on the authorization authentication code.
  • the establishment of a trust session with the client based on the legality verification result for the maintained login identifier includes : If the validity verification result indicates that the verification is successful, a new session identifier is sent to the client, so that the client establishes a trust session with the central server based on the new session identifier.
  • the computer executable instructions stored in the storage medium in one or more embodiments of this specification When executed by the processor, they receive a keep-login request from the client, where the keep-login request carries a locally pre-stored keep-login identifier, and the keep-login request The identification is sent by the central server for the client's authorized login request. In response to the log-in retention request, a trusted session with the client is established based on the log-in retention identifier.
  • the central server sends the corresponding session identifier and the hold login identification to the client at the same time, so that subsequent clients can directly base on the hold
  • the login ID requests to keep logged in, so that there is no need to perform the complicated interactive process of authorized login during the period of keeping the login ID valid, which reduces the frequency of authorized login calls, thereby simplifying the interaction steps of establishing a trust session between the client and the central server. Ensure that the client can safely log in to the SAAS service of the center server, and improve the efficiency of the client's secure login.
  • the improvement of a technology can be clearly distinguished between hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method flow).
  • hardware improvements for example, improvements in circuit structures such as diodes, transistors, switches, etc.
  • software improvements improvements in method flow.
  • the improvement of many methods and processes of today can be regarded as a direct improvement of the hardware circuit structure.
  • Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by the hardware entity module.
  • a programmable logic device Programmable Logic Device, PLD
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HD Cal JHDL
  • Java Hardware Description Language Lava, Lola, My HDL, PALASM, RHDL (Ruby Hardware Description), etc.
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the controller can be implemented in any suitable manner.
  • the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program codes (such as software or firmware) executable by the (micro)processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as part of the memory control logic.
  • controllers in addition to implementing the controller in a purely computer-readable program code manner, it is entirely possible to program the method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers, and embedded logic.
  • the same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as a structure within the hardware component. Or even, the device for realizing various functions can be regarded as both a software module for realizing the method and a structure within a hardware component.
  • a typical implementation device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.
  • one or more of the embodiments in this specification can be provided as a method, a system, or a computer program product. Therefore, one or more of this specification may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, one or more of this specification can adopt computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. form.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • the computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM).
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • one or more of the embodiments in this specification can be provided as a method, a system, or a computer program product. Therefore, one or more of this specification may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, one or more of this specification can adopt computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. form.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • program modules can also be practiced in a distributed computing environment. In these distributed computing environments, tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

Abstract

本说明书一个或多个实施例提供了一种会话建立方法、跨境支付方法、装置及系统，其中，该会话建立方法包括：在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若客户端本地不存在会话标识符，则判断本地是否存在保持登录标识，其中，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。若客户端本地存在保持登录标识，则基于保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于该保持登录请求并建立与客户端之间的信任会话。

Description

会话建立方法、跨境支付方法、装置及系统 技术领域
本文涉及互联网技术领域，尤其涉及一种会话建立方法、跨境支付方法、装置及系统。
背景技术
目前，随着互联网技术的快速发展，移动支付的应用场景越来越普及，同时，用户通过客户端进行跨境支付的需求越来越高，即消费者所安装的支付应用与商家所支持的支付应用属于不同国家的支付系统，例如，海外客户端通过支付应用与大陆商户之间进行支付，又如，大陆客户端通过大陆支付应用与海外商户之间进行支付。
其中，在跨境支付过程中，需要在客户端与中心服务端之间建立可信会话。现有技术中提供的会话建立过程主要是：客户端基于用户标识直接调用中心服务端的进行登录，以实现在客户端与中心服务端之间建立可信会话，在此过程中，由于用户标识的可信度比较低，无法实现安全登录。
由此可知，需要提供一种针对客户端和中心服务端之间的安全性高且登录效率高的会话建立的技术方案。
发明内容
本说明书一个或多个实施例的目的是提供一种会话建立方法。应用于客户端，所述客户端与中心服务端通信连接，该会话建立方法包括：在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
本说明书一个或多个实施例的目的是提供一种会话建立方法。应用于中心服务端，所述中心服务端与客户端通信连接，该会话建立方法包括：接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
本说明书一个或多个实施例的目的是提供一种跨境支付方法。应用于客户端，所述客户端与中心服务端通信连接，该跨境支付方法包括：在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求并执行相应的跨境支付操作。
本说明书一个或多个实施例的目的是提供一种跨境支付方法。应用于中心服务端，所述中心服务端与客户端通信连接，该跨境支付方法包括：接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。接收所述客户端发送的跨境支付请求，并执行相应的跨境支付操作。
本说明书一个或多个实施例的目的是提供一种会话建立装置。设置于客户端，所述客户端与中心服务端通信连接，该会话建立装置包括：第一判断模块，其在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。第二判断模块，其若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所 述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。会话建立模块，其若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
本说明书一个或多个实施例的目的是提供一种会话建立装置。设置于中心服务端，所述中心服务端与客户端通信连接，该会话建立装置包括：保持登录请求接收模块，其接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。信任会话建立模块，其响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
本说明书一个或多个实施例的目的是提供一种跨境支付装置。设置于客户端，所述客户端与中心服务端通信连接，该跨境支付装置包括：第一判断模块，其在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。第二判断模块，其若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。会话建立模块，其若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。跨境支付请求发送模块，其向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求并执行相应的跨境支付操作。
本说明书一个或多个实施例的目的是提供一种跨境支付装置。设置于中心服务端，所述中心服务端与客户端通信连接，该跨境支付装置包括：保持登录请求接收模块，其接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。信任会话建立模块，其响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。跨境支付处理模块，其接收所述客户端发送的跨境支付请求，并执行相应的跨境支付操作。
本说明书一个或多个实施例的目的是提供一种会话建立系统，包括：客户端和中心服务端，所述客户端与所述中心服务端通信连接。
其中，所述客户端包括上述包含第一判断模块、第二判断模块和会话建立模块的会话建立装置。所述中心服务端包括上述包含保持登录请求接收模块和信任会话建立模块的会话建立装置。
本说明书一个或多个实施例的目的是提供一种跨境支付系统，包括：客户端和中心服务端，所述客户端与所述中心服务端通信连接。
其中，所述客户端包括上述包含第一判断模块、第二判断模块、会话建立模块和支付请求发送模块的跨境支付装置。所述中心服务端包括上述包含保持登录请求接收模块、信任会话建立模块和跨境支付处理模块的跨境支付装置。
本说明书一个或多个实施例的目的是提供一种会话建立设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器。
所述计算机可执行指令在被执行时使所述处理器在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
本说明书一个或多个实施例的目的是提供一种会话建立设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器。
所述计算机可执行指令在被执行时使所述处理器接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
本说明书一个或多个实施例的目的是提供一种存储介质，用于存储计算机可执行指令。所述可执行指令在被处理器执行时在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
本说明书一个或多个实施例的目的是提供一种存储介质，用于存储计算机可执行指令。所述可执行指令在被处理器执行时接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的。响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
附图说明
为了更清楚地说明本说明书一个或多个实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书一个或多个中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本说明书一个或多个实施例提供的会话建立系统的应用场景示意图；
图2为本说明书一个或多个实施例提供的会话建立方法的第一种流程示意图；
图3为本说明书一个或多个实施例提供的会话建立方法的第二种流程示意图；
图4为本说明书一个或多个实施例提供的会话建立方法的第三种流程示意图；
图5为本说明书一个或多个实施例提供的会话建立方法中客户端与中心服务端之间的信息交互过程的第一种示意图；
图6为本说明书一个或多个实施例提供的会话建立方法的第四种流程示意图；
图7为本说明书一个或多个实施例提供的会话建立方法中客户端与中心服务端之间的信息交互过程的第二种示意图；
图8为本说明书一个或多个实施例提供的会话建立方法的第五种流程示意图；
图9为本说明书一个或多个实施例提供的执行主体为中心服务端的会话建立方法的流程示意图；
图10为本说明书一个或多个实施例提供的执行主体为客户端的跨境支付方法的流程示意图；
图11为本说明书一个或多个实施例提供的执行主体为中心服务端的跨境支付方法的流程示意图；
图12为本说明书一个或多个实施例提供的设置于客户端的会话建立装置的模块组成示意图；
图13为本说明书一个或多个实施例提供的设置于中心服务端的会话建立装置的模块组成示意图；
图14为本说明书一个或多个实施例提供的会话建立设备的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书一个或多个中的技术方案，下面将结合本说明书一个或多个实施例中的附图，对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一个或多个一部分实施 例，而不是全部的实施例。基于本说明书一个或多个中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本本文件的保护范围。
需要说明的是，在不冲突的情况下，本说明书中的一个或多个实施例以及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本说明书一个或多个实施例。
本说明书一个或多个实施例提供了一种会话建立方法、跨境支付方法、装置及系统，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
图1为本说明书一个或多个实施例提供的会话建立系统的应用场景示意图，如图1所示，该系统包括：中心服务端、多个客户端和多个支付服务端。其中，该客户端可以是智能手机、平板电脑等移动终端，该客户端还可以是物联网设备等终端设备，该客户端可以是消费者所使用的用户终端，还可以是商家所述使用的用户终端，该客户端设置有预设软件开发工具包SDK，并通过该SDK接入全球网络GN(即Alipay GlobalNet网络)与中心服务端通信连接。其中，该中心服务端可以是通过全球网络GN将支持不同国家支付的支付应用之间互联互通的后台服务器，以实现客户端的跨境支付，该中心服务端可以是具有saas服务的独立的服务器，也可以是由具有saas服务的多个服务器组成的服务器集群。其中，该支付服务端可以是用于对客户端所安装的支付应用进行管控的后台服务器，该支付服务端接入全球网络GN与中心服务端通信连接，不同支付服务端通过各自的支付应用为客户端提供支付服务，因此，若消费者所用的支付应用对应的支付服务端1与商家所支持的支付应用对应的支付服务端2属于不同国家，即消费者客户端上安装的支付应用属于海外支付应用，消费者与商家之间属于跨境支付，此时，需要客户端与中心服务端之间建立信任会话，再由中心服务端与消费者和商家分别对应的支付服务端进行信息交互，从而使得消费者和商家之间实现跨境支付。
具体的，客户端与中心服务端之间的会话建立的具体过程为：客户端在检测到用户针对支付应用的预设业务触发操作后，判断本地是否存在会话标识符sessionId；客户端若确定本地存在会话标识符sessionId，则向中心服务端发送携带有该会话标识符sessionId的跨境支付请求，以使中心服务端基于该会话标识符sessionId响应于客户端的跨境支付请求并向客户端发送相应的反馈指示；客户端若确定本地不存在会话标识符sessionId，则判断本地是否存在保持登录标识clientKey。
(1)针对本地存在保持登录标识clientKey的情况，客户端基于该保持登录标识clientKey，向中心服务端发送保持登录请求；中心服务端响应于客户端的保持登录请求，对该保持登录请求中携带的保持登录标识clientKey进行合法性验证；中心服务端若确定clientKey合法性验证通过，则向客户端返回一个新的会话标识符sessionId；客户端在接收到中心服务端返回的新的会话标识符sessionId后，基于该sessionId与中心服务端建立信任会话。
(2)针对本地不存在保持登录标识clientKey的情况，客户端基于支付应用对应的支付服务端所颁发的授权认证码，向中心服务端发送授权登录请求；中心服务端响应于客户端的授权登录请求，向支付应用对应的支付服务端请求对上述授权认证码进行合法性验证；中心服务端若接收到针对授权验证码的合法性验证通过结果，则向客户端返回一个新的会话标识符sessionId和保持登录标识clientKey；客户端在接收到新的会话标识符sessionId和保持登录标识clientKey后，基于该sessionId与中心服务端建立信任会 话，以及存储该clientKey，其中，后续客户端可以基于该clientKey向中心服务端请求保持登录，以使客户端与中心服务端之间建立信任会话，即建立客户端的SDK与中心服务端的SAAS服务之间的信任会话。
基于上述应用场景的具体实现过程，在客户端与中心服务端之间建立信任会话的过程中，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保设置有接入GN的SDK的客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
图2为本说明书一个或多个实施例提供的会话建立方法的第一种流程示意图，图2中的方法能够由图1中的客户端执行，具体的可以由客户端中设置的SDK执行，如图2所示，该方法至少包括以下步骤：
S202，在检测到预设业务触发操作后，判断本地是否存在会话标识符；其中，该预设业务触发操作可以是用户针对客户端上安装的支付应用的触控操作；
其中，上述预设业务触发操作可以是用户通过支付应用中的扫码功能进行扫码操作，还可以是用户对支付应用中的付款控件的点击操作；
在具体实施时，针对线下支付的情况，在不同的当前使用场景下，客户端上安装的支付应用可以是本地支付应用(即本地支付电子钱包)，还可以是支付应用(即海外支付电子钱包)，因此，在判断本地是否存在会话标识符之前，需要先根据消费者客户端所使用的支付应用的第一属性信息与商户客户端所接入的支付系统的第二属性信息是否相匹配，确定消费者客户端上安装的支付应用是否属于海外支付应用。例如，菲律宾用户使用菲律宾钱包APP与大陆商户进行支付，又如，大陆用户使用大陆钱包APP与菲律宾商户进行支付，具体的，若第一属性信息和第二属性信息之间不匹配，即买卖双方对应的支付服务端的所属国家不同，则确定客户端上安装的支付应用为海外支付应用，买卖双方之间的支付属于跨境支付，例如，针对消费者通过客户端所安装的支付应用扫描商户用于收款的图形码的情况，如果消费者客户端上安装的支付应用对应的支付服务端服务于第一区域的用户(即消费者客户端为在第一区域内使用的客户端)，而商家提供的用于收款的图形码对应的支付服务端服务于第二区域的用户(即用户收款的图形码为在第二区域内使用的图形码)，若第一区域与第二区域不同，则确定消费者客户端上安装的支付应用为海外支付应用。此时，需要客户端与中心服务端之间建立信任会话，即开始执行上述步骤S202，判断本地是否存在会话标识符。
若存在会话标识符，则执行S204，基于本地的会话标识符向中心服务端发送跨境业务请求，以使该中心服务端响应于该跨境业务请求并向客户端返回相应的指示信息。
若不存在会话标识符，则执行S206，判断本地是否存在保持登录标识，其中，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。
若不存在保持登录标识，则执行S208，向中心服务端发送授权登录请求，以使该中心服务端响应于该授权登录请求并与客户端建立信任会话。
若存在保持登录标识，则执行S210，基于本地预存的保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于该保持登录请求并建立与客户端之间的信任会话。
具体的，在确定不存在会话标识符后，确定客户端本地是否存在保持登录标识，进而根据保持登录标识存在与否的判断结果，向中心服务端发送相应的登录请求；其中，针对存在保持登录标识的情况，客户端可以通过该保持登录标识，向中心服务端请求保持登录，从而提高客户端的安全登录效率。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过 程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
进一步的，在客户端与中心服务端之间完成信任会话建立之后，上述方法还包括：向中心服务端发送跨境支付请求，以使中心服务端响应于跨境支付请求；其中，上述跨境支付请求是在第一区域内使用的客户端对在第二区域内使用的图形码执行扫码操作所生成的，该第一区域与第二区域不同。
具体的，若客户端上安装的支付应用对应的支付服务端的目标服务区域为第一区域，客户端在检测到针对在第二区域内使用的图形码的扫描操作后，基于该图形码的信息生成跨境支付请求，并在客户端与中心服务器之间完成信任会话建立后，将该跨境支付请求发送至中心服务器；
其中，上述第一区域可以是与第二区域不同的区域，即可以是以不同的国家为界限的不同区域，还可以是以不同的指定的地理区域范围为界限的不同区域，例如，第一区域可以是某一个国家对应的区域，第二区域可以是另一个国家对应的区域等。对应的，针对第一区域与第二区域所属的国家不同的情况，客户端上安装的支付应用可以称为海外支付应用，即用户使用客户端在其安装的支付应用对应的支付服务端所服务的国家之外的其他国家进行跨境支付。
其中，针对客户端本地存在保持登录标识的情况，为了提高保持登录标识的传输安全性，防止保持登录标识被截获或被篡改，基于此，如图3所示，上述S210，基于本地预存的保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于该保持登录请求并建立与客户端之间的信任会话，具体包括：S2101，基于本地预存的保持登录标识，生成用于发起保持登录的保持登录请求；S2102，向中心服务端发送上述保持登录请求，以使该中心服务端基于该保持登录请求建立与客户端之间的信任会话。
具体的，在确定本地存在保持登录标识后，对保持登录标识进行签名处理，生成携带有签名后的保持登录标识clientKey的保持登录请求，并向中心服务端发送该保持登录请求，以使中心服务端对该签名后的保持登录标识进行合法性验证，从而确保保持登录请求未被篡改；
在具体实施时，在向中心服务端发送携带有保持登录标识clientKey的保持登录请求之前，可以先对保持登录标识clientKey进行加密签名，生成相应的登录请求摘要clientKeyDigest，再生成携带有该登录请求摘要的保持登录请求，再向中心服务端发送该保持登录请求，这样能够以消息摘要的形式向中心服务端传输保持登录标识clientKey，从而确保保持登录标识clientKey的传输安全性。
具体的，针对保持登录请求的生成过程，如图4所示，上述S2101，基于本地预存的保持登录标识，生成用于发起保持登录的保持登录请求，具体包括：S21011，确定登录请求生成因子，其中，该登录请求生成因子包括：时间戳和随机因子中至少一项；S21012，利用预设生成算法，根据本地预存的保持登录标识和确定出的登录请求生成因子，生成用于发起保持登录的保持登录请求。
在具体实施时，针对先基于保持登录标识生成登录请求摘要，再基于登录请求摘要生成保持登录请求的情况，登录请求生成因子即为摘要生成因子，在确定出摘要生成因子后，先利用预设摘要生成算法，基于本地预存的保持登录标识和确定出的摘要生成因子，生成登录请求摘要，再基于该登录请求摘要生成保持登录请求，即该保持登录请求中携带有登录请求摘要；
具体的，针对登录请求摘要的生成过程，获取时间戳timestamp，以及生成随机因子nonce；采用预设摘要生成算法，对保持登录标识clientKey、时间戳timestamp、随机 因子nonce进行摘要计算，得到相应的登录请求摘要clientKeyDigest。其中，该预设摘要生成算法可以是SHA256算法，还可以是MD5算法，也可以是多个摘要算法的组合；
其中，为了进一步提高保持登录标识的传输安全性，上述预设摘要生成算法可以是根据在摘要算法集合中随机选取的至少一个摘要算法确定，其中，针对预设摘要生成算法为多个摘要算法的组合的情况，该多个摘要算法的先后使用顺序是随机的，这样每次使用的预设摘要生成算法是动态变化的且不可预测的，避免因预设摘要生成算法被泄露而降低保持登录标识的传输安全性的问题。
在具体实施时，如图5所示，给出了客户端与中心服务端之间的信息交互过程的示意图，具体包括以下步骤。
S501，客户端检测针对支付应用的预设业务触发操作
S502，客户端判断本地是否存在会话标识符sessionId。
S503，若存在会话标识符sessionId，则向中心服务端发送携带有该会话标识符sessionId的跨境支付请求，以使中心服务端基于该会话标识符sessionId响应于客户端的跨境支付请求并向客户端发送相应的反馈指示。
S504，若不存在会话标识符sessionId，则判断本地是否存在保持登录标识clientKey。
S505，若不存在保持登录标识clientKey，则向中心服务端发送授权登录请求，以使中心服务端响应于该客户端的授权登录请求并建立与客户端之间的信任会话。
S506，若存在保持登录标识clientKey，则基于本地的clientKey、时间戳和随机因子生成clientKeyDigest。
S507，客户端向中心服务端发送携带有clientKeyDigest的保持登录请求。
S508，中心服务端在接收到保持登录请求后，基于clientKeyDigest对clientKey进行合法性验证，生成针对clientKey的合法性验证结果。
S509，中心服务端若clientKey合法性验证通过，则向客户端发送新的会话标识符sessionId。
S510，客户端将接收到的sessionId写入本地cookie，与中心服务端建立信任会话。
其中，针对客户端本地不存在保持登录标识的情况，此时可以采用授权登录的方式与中心服务端建立信任会话，基于此，如图6所示，在上述S208，向中心服务端发送授权登录请求，以使该中心服务端响应于该授权登录请求并与客户端建立信任会话，具体包括：S2081，基于客户端的授权认证码，向中心服务端发送授权登录请求，以使该中心服务端响应于该授权登录请求并返回新的会话标识符和保持登录标识；其中，该授权认证码理论上是客户端上安装的支付应用对应的支付服务端为客户端所颁发的；
S2082，存储中心服务端返回的保持登录标识；S2083，基于中心服务端返回的新的会话标识符，与中心服务端之间建立信任会话；具体的，客户端在确定本地不存在保持登录标识clientKey后，向中心服务端发送携带有支付服务端所颁发的授权认证码authorCode的授权登录请求；中心服务端基于该授权登录请求，向客户端返回新的会话标识符和保持登录标识；
具体的，客户端在接收到中心服务端返回的新的会话标识符sessionId和保持登录标识clientKey之后，存储该clientKey，以便后续基于该clientKey请求保持登录；以及将该sessionId写入本地cookie，与中心服务端建立信任会话，从而完成客户端的授权登录，然后，客户端可以基于该新的sessionId向中心服务端发送相应的跨境支付请求。
其中，为了进一步提高会话建立的安全性，需要对客户端所发送的授权认证码进行合法性验证，只有授权认证码的合法性验证通过后才允许客户端能够安全登录中心服务端，基于此，上述S2081，基于客户端的授权认证码，向中心服务端发送授权登录请求，以使该中心服务端响应于该授权登录请求并返回新的会话标识符和保持登录标识，具体包括：
步骤一，基于客户端的授权认证码，生成用于发起授权登录的授权登录请求，具 体的，该授权登录请求携带有该授权登录码；
步骤二，向中心服务端发送上述授权登录请求，以使该中心服务端基于该授权认证码向支付服务端请求合法性验证、并在接收到针对该授权认证码的合法性验证通过时返回新的会话标识符和保持登录标识。
具体的，客户端向支付应用对应的支付服务端发送授权认证码获取请求；在接收到支付服务端返回的授权认证码authorCode后，向中心服务端发送携带有该authorCode的授权登录请求。
中心服务端在接收到客户端的授权登录请求后，向与客户端对应的支付服务端发送携带有授权认证码authorCode的合法性验证请求，以使支付服务端对该authorCode进行合法性验证；具体的，支付服务端根据预存的用户标识userId与授权认证码authorCode之间的对应关系，判断客户端的authorCode的合法性。
中心服务端若接收到支付服务端针对上述authorCode的合法性验证通过结果和客户端对应的用户标识userId，则向客户端返回新的会话标识符sessionId和保持登录标识clientKey。
客户端在接收到中心服务端返回的新的会话标识符sessionId和保持登录标识clientKey之后，存储该clientKey，以及将该sessionId写入本地cookie，与中心服务端建立信任会话，从而完成客户端的授权登录，然后，客户端可以基于该新的sessionId向中心服务端发送相应的跨境支付请求，其中，由于基于可信的授权认证码authorCode完成客户端的授权登录，这样能够防止后续业务PRC被恶意攻击。
其中，考虑到可能存在恶意用户采用非法分子盗用客户端的保持登录标识的问题，为了确保保持登录标识的存储安全性，提高保持登录标识的盗取难度，基于此，上述S2082，存储中心服务端返回的保持登录标识，具体包括：将中心服务端返回的保持登录标识存入客户端中预设的无线保镖；其中，该无线保镖的防攻击系数大于预设阈值。
其中，在中心服务端在响应客户端的授权登录请求的过程中，中心服务端在确定授权认证码authorCode的合法性验证通过后，不仅需要向客户端返回新的会话标识符和保持登录标识，还需要存储客户端的用户标识userId与会话标识符sessionId和保持登录标识clientKey之间的对应关系；
具体的，采用如下数据结构1和数据结构2存储用户标识userId与会话标识符sessionId之间的对应关系，以及采用如下数据结构3存储用户标识userId与保持登录标识clientKey之间的对应关系，通过userId与sessionId关系数据，维持sessionId的有效性，通过userId与clientKey关系数据，维持clientKey的有效性。
其中，数据结构1：session主数据
key：
AC_SESSION_KEY_${sessionId}
value：
{
“userId”：“2102xxxxx”，
“tid”：“xxx”
}
expire：15min
其中，数据结构2：session幂等数据
key：
AC_SESSION_IDEMPOTENT_KEY_${userId}
value：
{
“sessionId”：“2102xxxxx”，
“tid”：“xxx”
}
expire：15min
其中，数据结构3：clientKey关系数据
key：
AC_CLIENT_KEY_RELATION_${userId}
value：
{
“clientKey”：“xxxxxxx”，
}
expire：15days
其中，在具体实施时，针对授权登录的过程，如图7所示，给出了客户端、支付服务端、中心服务端之间的信息交互过程的示意图，具体包括以下步骤。
S701，客户端检测针对支付应用的预设业务触发操作。
S702，客户端判断本地是否存在会话标识符sessionId。
S703，若存在会话标识符sessionId，则向中心服务端发送携带有该会话标识符sessionId的跨境支付请求，以使中心服务端基于该会话标识符sessionId响应于客户端的跨境支付请求并向客户端发送相应的反馈指示。
S704，若不存在会话标识符sessionId，则判断本地是否存在保持登录标识clientKey。
S705，若不存在保持登录标识clientKey，则向相应的支付服务端发送授权认证码获取请求。
S706，支付服务端向客户端返回对应的授权认证码authorCode。
S707，客户端向中心服务端发送携带有授权认证码authorCode的授权登录请求。
S708，中心服务端向支付服务端请求验证授权认证码authorCode的合法性。
S709，支付服务端在确定authorCode的合法性验证通过后，向中心服务端发送针对authorCode的合法性验证通过结果和用户标识userId。
S710，中心服务端向客户端发送新的会话标识符sessionId和保持登录标识clientKey。
S711，客户端存储中心服务端返回的clientKey。
S712，客户端将中心服务端返回的sessionId写入本地cookie，与中心服务端建立信任会话。
S713，若存在保持登录标识clientKey，则客户端基于本地的clientKey生成保持登录请求。
S714，客户端向中心服务端发送保持登录请求。
S715，中心服务端响应于该客户端的保持登录请求并建立与客户端之间的信任会话。
进一步的，针对客户端本地存在会话标识符的情况，此时可以直接向中心服务端请求跨境支付业务，考虑到该会话标识符可能已失效，为了进一步提高客户端能够安全登录的控制精准度，从而提高跨境业务处理的安全性，中心服务端先对客户端发送的会话标识符进行合法性验证，若合法性验证不通过，向客户端返回相应的提示信息，以触发客户端重新进行安全登录，基于此，如图8所示，在上述S204，基于本地的会话标识符向中心服务端发送跨境业务请求，以使该中心服务端响应于该跨境业务请求并向客户端返回相应的指示信息，具体包括：S2041，向中心服务端发送携带有该会话标识符的跨境业务请求，以使中心服务端对该会话标识符进行合法性验证；S2042，接收中心服务端返回的针对会话标识符的验证失败结果，以及继续执行上述S206，判断本地是 否存在保持登录标识的步骤。
具体的，客户端在确定本地cookie中存在会话标识符sessionID之后，基于已有的sessionID向中心服务端发起RPC(Remote Procedure Call，远程过程调用)。
中心服务端对客户端所发送请求中携带的sessionID进行合法性验证，得到针对该sessionID的合法性验证结果；具体的，确定与客户端对应的userId与sessionId关系数据(即上述数据结构1和数据结构2)，根据该关系数据判断客户端所发送请求中携带的sessionID是否已失效，若否，则响应于客户端的跨境业务请求并执行相应的跨境支付操作，以及在跨境支付完成后返回相应的支付信息；若是，则确定针对sessionID的合法性验证失败，并向客户端发送针对会话标识符的验证失败结果。
进一步的，针对客户端本地存在保持登录标识的情况，而该保持登录标识也可能已失效，此时客户端无法直接完成保持登录，需要客户端重新采用授权登录的方式向中心服务端请求信任会话建立，基于此，上述S2102，向中心服务端发送上述保持登录请求，以使该中心服务端基于该保持登录请求建立与客户端之间的信任会话，具体包括：向中心服务端发送所生成的保持登录请求，以使该中心服务端基于该保持登录请求对保持登录标识进行合法性验证；若接收到中心服务端针对保持登录标识的验证失败结果，则基于客户端的授权认证码，向中心服务端发送授权登录请求，以使中心服务端响应于该授权登录请求并建立与客户端之间的信任会话。
具体的，针对先基于保持登录标识生成登录请求摘要，再基于登录请求摘要生成保持登录请求的情况，客户端在确定本地存在保持登录标识clientKey后，基于该clientKey生成相应的登录请求摘要clientKeyDigest，向中心服务端发送携带有该clientKeyDigest的保持登录请求；其中，上述保持登录请求还携带有摘要生成因子，该摘要生成因子包括：时间戳和随机因子中至少一项；中心服务端在接收到客户端的保持登录请求后，获取预存的与客户端对应的保持登录标识clientKey；具体的，确定与客户端对应的userId与clientKey关系数据(即上述数据结构3)，根据该关系数据确定与客户端对应的保持登录标识clientKey；中心服务端利用预设摘要生成算法，根据获取到的保持登录标识和保持登录请求中携带的摘要生成因子，生成登录验证摘要；其中，该预设摘要生成算法与生成登录请求摘要clientKeyDigest所用的摘要生成算法相同。
具体的，针对中心服务端生成登录验证摘要的过程，若客户端生成登录请求摘要clientKeyDigest所用的预设摘要生成算法是随时间动态变化的，则客户端向中心服务端发送的保持登录请求还携带有摘要算法指示信息；中心服务端根据该摘要算法指示信息，确定生成登录请求摘要clientKeyDigest所使用的预设摘要生成算法；其中，该摘要算法指示信息可以是按照预设编码规则编码后的信息，中心服务端基于对应的解码规则进行解密，得到解码后的摘要算法指示信息，再根据解码后的摘要算法指示信息，确定生成登录请求摘要clientKeyDigest所使用的预设摘要生成算法；中心服务端利用确定出的预设摘要生成算法，根据获取到的保持登录标识和保持登录请求中携带的摘要生成因子，生成登录验证摘要。
若保持登录请求中携带的登录请求摘要与中心服务端所生成的登录验证摘要不一致，则确定针对客户端本地存在的保持登录标识clientKey的合法性验证不通过；中心服务端向客户端返回针对保持登录标识的合法性验证失败结果，以触发客户端重新向中心服务端发送授权登录请求。
需要说明的是，客户端重新向中心服务端请求授权登录的过程与上述针对客户端本地不存在保持登录标识的情况所执行的授权登录的过程相同，在此不再赘述。
对应的，针对保持登录标识的合法性验证通过的情况，中心服务端将直接向客户端返回新的会话标识符，说明客户端可以采用保持登录的方式与中心服务端建立会话，基于此，在向中心服务端发送所生成的保持登录请求，以使该中心服务端基于该保持登录请求对保持登录标识进行合法性验证之后，还包括：若接收到中心服务端返回新的会 话标识符，则基于该新的会话标识符，与中心服务端之间建立信任会话；其中，上述新的会话标识符是在针对保持登录标识的合法性验证通过时中心服务端向客户端发送的。
具体的，若接收到的保持登录请求与中心服务端所生成的登录验证信息相匹配，则中心服务端确定针对保持登录标识的合法性验证结果通过，向客户端返回新的会话标识符sessionId。
在具体实施时，针对先基于保持登录标识生成登录请求摘要，再基于登录请求摘要生成保持登录请求的情况，若保持登录请求中携带的登录请求摘要与中心服务端所生成的登录验证摘要一致，则中心服务端确定针对保持登录请求中携带的保持登录标识clientKey的合法性验证结果通过，向客户端返回新的会话标识符sessionId。
其中，中心服务端在响应客户端的保持登录请求的过程中，若确定保持登录标识clientKey的合法性验证通过，不仅需要向客户端返回新的会话标识符sessionId，还需要存储客户端的用户标识userId与该会话标识符sessionId之间的对应关系，其中，用户标识userId与clientKey关系数据可以采用上述数据结构3进行存储。
客户端将中心服务端返回的新的sessionId写入本地cookie，与中心服务端建立信任会话，从而完成客户端的保持登录，然后，客户端可以基于该新的sessionId向中心服务端发送相应的跨境支付请求，其中，由于基于保持登录标识clientKey对应的登录请求摘要clientKeyDigest完成客户端的保持登录，这样能够防止后续业务PRC被恶意攻击。
本说明书一个或多个实施例中的会话建立方法，在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若客户端本地不存在会话标识符，则判断本地是否存在保持登录标识，其中，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。若客户端本地存在保持登录标识，则基于保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于该保持登录请求并建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
对应上述图2至图8描述的会话建立方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种会话建立方法，图9为本说明书一个或多个实施例提供的会话建立方法的流程示意图，图9中的方法能够由图1中的中心服务端执行，如图9所示，该方法至少包括以下步骤。
S902，接收客户端的保持登录请求，其中，该保持登录请求携带有本地预存的保持登录标识，该保持登录标识是中心服务端针对客户端的授权登录请求发送的。
具体的，客户端在确定出本地存在保持登录标识时向中心服务端发送保持登录请求。
S904，响应于接收到的保持登录请求，基于该保持登录标识建立与客户端之间的信任会话。
需要说明的是，中心服务端基于保持登录标识建立与客户端之间的信任会话的具体实现过程可以参见上述由客户端执行的会话建立方法中的相关步骤，在此不再赘述。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登 录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
进一步的，在客户端与中心服务端之间完成信任会话建立之后，上述方法还包括：接收客户端发送的跨境支付请求，并响应于该跨境支付请求；其中，上述跨境支付请求是在第一区域内使用的客户端对在第二区域内使用的图形码执行扫码操作所生成的，该第一区域与所述第二区域不同。
具体的，若客户端上安装的支付应用对应的支付服务端的目标服务区域为第一区域，客户端在检测到针对在第二区域内使用的图形码的扫描操作后，基于该图形码的信息生成跨境支付请求，并在客户端与中心服务器之间完成信任会话建立后，将该跨境支付请求发送至中心服务器；其中，上述第一区域可以是与第二区域不同的区域，即可以是以不同的国家为界限的不同区域，还可以是以不同的指定的地理区域范围为界限的不同区域，例如，第一区域可以是某一个国家对应的区域，第二区域可以是另一个国家对应的区域等。对应的，针对第一区域与第二区域所属的国家不同的情况，客户端上安装的支付应用可以称为海外支付应用，即用户使用客户端在其安装的支付应用对应的支付服务端所服务的国家之外的其他国家进行跨境支付。
其中，上述保持登录请求是基于保持登录标识所生成的；对应的，上述S904，响应于接收到的保持登录请求，基于该保持登录标识建立与客户端之间的信任会话，具体包括：对所述保持登录标识进行合法性验证，得到相应的合法性验证结果；基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话。
在具体实施时，客户端可以先对保持登录标识clientKey进行加密签名，生成相应的登录请求摘要clientKeyDigest，再生成携带有该登录请求摘要的保持登录请求，再向中心服务端发送该保持登录请求；对应的，中心服务端基于接收到的保持登录请求中携带的登录请求摘要clientKeyDigest，对保持登录标识进行合法性验证，得到相应的合法性验证结果，这样能够以消息摘要的形式向中心服务端传输保持登录标识clientKey，从而确保保持登录标识clientKey的传输安全性。
其中，上述保持登录请求还携带有登录请求生成因子；对应的，对所述保持登录标识进行合法性验证，得到相应的合法性验证结果，具体包括：获取与所述客户端对应的保持登录标识；利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于验证保持登录请求的登录验证信息；若所述保持登录请求与所述登录验证信息相匹配，则确定针对所述保持登录标识的合法性验证结果通过。
在具体实施时，针对先基于保持登录标识生成登录请求摘要，再基于登录请求摘要生成保持登录请求的情况，登录请求生成因子即为摘要生成因子，针对保持登录标识的合法性验证的过程，可以利用预设摘要生成算法，根据保持登录请求中携带的摘要生成因子、以及中心服务端预存的与客户端对应的保持登录标识，生成用于验证保持登录请求的登录验证摘要；再判断该登录验证摘要与客户端发送的登录请求摘要是否一致，若一致，则确定针对所述保持登录标识的合法性验证结果通过。
进一步的，在客户端确定本地不存在保持登录标识后，向中心服务端发送授权登录请求，以使中心服务端响应于该授权登录请求并建立与客户端之间的信任会话，具体的，上述方法还包括：接收客户端的授权登录请求，其中，所述授权登录请求是所述客户端确定本地不存在保持登录标识所发送的，且所述授权登录请求携带有所述客户端的授权认证码，所述授权认证码是所述客户端上安装的支付应用对应的支付服务端为所述客户端所颁发的；响应于所述授权登录请求，基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，以使所述客户端存储所述保持登录标识、并基于所述新的会话标识符与所述中心服务端建立信任会话。
其中，为了进一步提高会话建立的安全性，需要对客户端所发送的授权认证码进行合法性验证，只有授权认证码的合法性验证通过后才允许客户端能够安全登录中心服务端，基于此，上述基于所述授权认证码向所述客户端返回新的会话标识符和保持登录 标识，具体包括：基于所述授权认证码，向与所述客户端所触发的支付应用对应的支付服务端请求授权认证码合法性验证；若接收到针对所述授权认证码的合法性验证通过结果，则向所述客户端返回新的会话标识符和保持登录标识。
其中，中心服务端在确定授权认证码authorCode的合法性验证通过后，不仅需要向客户端返回新的会话标识符和保持登录标识，还需要存储客户端的用户标识userId与会话标识符sessionId和保持登录标识clientKey之间的对应关系，基于此，在基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识之后，还包括：存储所述客户端的用户标识与所述新的会话标识符和所述保持登录标识之间的对应关系。
其中，针对保持登录标识的合法性验证失败的情况，客户端需要重新向中心服务端发送授权登录请求，基于此，上述基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，具体包括：若所述合法性验证结果表征验证失败，则向所述客户端发送合法性验证失败结果，以使所述客户端基于从对应的支付服务端获取的授权认证码向所述中心服务端发送授权登录请求；响应于所述授权登录请求，基于所述授权认证码建立与所述客户端之间的信任会话。
需要说明的是，中心服务端基于授权认证码建立与客户端之间的信任会话的具体实现过程可以参见上述由客户端执行的会话建立方法中的相关步骤，在此不再赘述。
其中，针对保持登录标识的合法性验证通过的情况，中心服务端直接向客户端返回新的会话标识符，以使客户端进行信任会话建立，基于此，所述基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，具体包括：
若所述合法性验证结果表征验证通过，则向所述客户端发送新的会话标识符，以使所述客户端基于所述新的会话标识符与所述中心服务端建立信任会话。
本说明书一个或多个实施例中的会话建立方法，接收客户端的保持登录请求，其中，该保持登录请求携带有本地预存的保持登录标识，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。响应于该保持登录请求，基于保持登录标识建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
需要说明的是，本说明书中该实施例与本说明书中上一实施例基于同一发明构思，因此该实施例的具体实施可以参见前述会话建立方法的实施，重复之处不再赘述。
对应上述图2至图8描述的会话建立方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种跨境支付方法，图10为本说明书一个或多个实施例提供的跨境支付方法的流程示意图，图10中的方法能够由图1中的客户端执行，具体的可以由客户端中设置的SDK执行，如图10所示，该方法至少包括以下步骤。
S1002，在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。
S1004，若不存在会话标识符，则判断本地是否存在保持登录标识，其中，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。
S1006，若存在保持登录标识，则基于该保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于保持登录请求并建立与客户端之间的信任会话。
S1008，向中心服务端发送跨境支付请求，以使中心服务端响应于跨境支付请求并执行相应的跨境支付操作。
具体的，基于客户端所扫描的图形码的信息，生成跨境支付请求，并向所述中心服务端发送所述跨境支付请求；
其中，上述跨境支付请求是在第一区域内使用的客户端对在第二区域内使用的图形码执行扫码操作所生成的，该第一区域与第二区域不同。
本说明书一个或多个实施例中的跨境支付方法，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率，进而提高中心服务端针对客户端的跨境支付请求的响应效率。
需要说明的是，本说明书中该实施例与本说明书中前述实施例基于同一发明构思，因此该实施例的具体实施可以参见前述会话建立方法的实施，重复之处不再赘述。
对应上述图2至图8描述的会话建立方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种跨境支付方法，图11为本说明书一个或多个实施例提供的跨境支付方法的流程示意图，图11中的方法能够由图1中的中心服务端执行，如图11所示，该方法至少包括以下步骤。
S1102，接收客户端的保持登录请求，其中，该保持登录请求携带有本地预存的保持登录标识，该保持登录标识是中心服务端针对客户端的授权登录请求发送的。
S1104，响应于上述保持登录请求，基于上述保持登录标识建立与客户端之间的信任会话。
S1106，接收客户端发送的跨境支付请求，并执行相应的跨境支付操作。
具体的，接收客户端基于其扫描的图形码的信息所生成的跨境支付请求；
其中，上述跨境支付请求是在第一区域内使用的客户端对在第二区域内使用的图形码执行扫码操作所生成的，该第一区域与所述第二区域不同。
本说明书一个或多个实施例中的跨境支付方法，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率，进而提高中心服务端针对客户端的跨境支付请求的响应效率。
需要说明的是，本说明书中该实施例与本说明书中前述实施例基于同一发明构思，因此该实施例的具体实施可以参见前述会话建立方法的实施，重复之处不再赘述。
对应上述图2至图8描述的会话建立方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种会话建立装置，该装置设置于图1中的客户端，图12为本说明书一个或多个实施例提供的会话建立装置的模块组成示意图，该装置用于执行图2至图8描述的会话建立方法，如图12所示，该装置包括：第一判断模块1201，其在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；第二判断模块1202，其若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；会话建立模块1203，其若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而 简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
可选地，上述装置还包括：跨境请求发送模块，其：向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
可选地，上述会话建立模块1203，其基于所述保持登录标识，生成用于发起保持登录的保持登录请求；向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求建立与所述客户端之间的信任会话。
可选地，上述会话建立模块1203，其确定登录请求生成因子，其中，所述登录请求生成因子包括：时间戳和随机因子中至少一项；利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于发起保持登录的保持登录请求。
可选地，上述会话建立模块1203，其若不存在保持登录标识，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并返回新的会话标识符和保持登录标识；其中，所述授权认证码是所述支付应用对应的支付服务端为所述客户端所颁发的；存储所述保持登录标识，并基于所述新的会话标识符，与所述中心服务端之间建立信任会话。
可选地，上述会话建立模块1203，其基于所述客户端的授权认证码，生成用于发起授权登录的授权登录请求；向所述中心服务端发送所述授权登录请求，以使所述中心服务端基于所述授权认证码向所述支付服务端请求合法性验证、并在接收到针对所述授权认证码的合法性验证通过时返回新的会话标识符和保持登录标识。
可选地，上述会话建立模块1203，其若存在会话标识符，则向所述中心服务端发送携带有所述会话标识符的跨境业务请求，以使所述中心服务端对所述会话标识符进行合法性验证；若接收到所述中心服务端针对所述会话标识符的验证失败结果，则执行判断本地是否存在保持登录标识的步骤。
可选地，上述会话建立模块1203，其向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求对所述保持登录标识进行合法性验证；若接收到所述中心服务端针对所述保持登录标识的验证失败结果，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并建立与所述客户端之间的信任会话。
可选地，上述会话建立模块1203，其若接收到所述中心服务端返回新的会话标识符，则基于所述新的会话标识符，与所述中心服务端之间建立信任会话；其中，所述新的会话标识符是在针对所述保持登录标识的合法性验证通过时向所述客户端发送的。
本说明书一个或多个实施例中的会话建立装置，在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若客户端本地不存在会话标识符，则判断本地是否存在保持登录标识，其中，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。若客户端本地存在保持登录标识，则基于保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于该保持登录请求并建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
需要说明的是，本说明书中关于会话建立装置的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话 建立方法的实施，重复之处不再赘述。
对应上述图9描述的会话建立方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种会话建立装置，该装置设置于图1中的中心服务端，图13为本说明书一个或多个实施例提供的会话建立装置的模块组成示意图，该装置用于执行图9描述的会话建立方法，如图13所示，该装置包括：保持登录请求接收模块1301，其接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；信任会话建立模块1302，其响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
可选地，上述装置还包括：跨境请求接收模块，其：接收所述客户端发送的跨境支付请求，并响应于所述跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
可选地，上述信任会话建立模块1302，其对所述保持登录标识进行合法性验证，得到相应的合法性验证结果；基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话。
可选地，所述保持登录请求还携带有登录请求生成因子；对应的，上述信任会话建立模块1302，其获取与所述客户端对应的保持登录标识；利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于验证所述保持登录请求的登录验证信息；若所述保持登录请求与所述登录验证信息相匹配，则确定针对所述保持登录标识的合法性验证结果通过。
可选地，上述装置还包括：授权登录请求接收模块，其接收所述客户端的授权登录请求，其中，所述授权登录请求是所述客户端确定本地不存在保持登录标识所发送的，且所述授权登录请求携带有所述客户端的授权认证码，所述授权认证码是所述客户端上安装的支付应用对应的支付服务端为所述客户端所颁发的；
对应的，上述信任会话建立模块1302，其响应于所述授权登录请求，基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，以使所述客户端存储所述保持登录标识、并基于所述新的会话标识符与所述中心服务端建立信任会话。
可选地，上述信任会话建立模块1302，其基于所述授权认证码，向与所述客户端所触发的支付应用对应的支付服务端请求授权认证码合法性验证；若接收到针对所述授权认证码的合法性验证通过结果，则向所述客户端返回新的会话标识符和保持登录标识。
可选地，上述信任会话建立模块1302，其存储所述客户端的用户标识与所述新的会话标识符和所述保持登录标识之间的对应关系。
可选地，上述信任会话建立模块1302，其若所述合法性验证结果表征验证失败，则向所述客户端发送合法性验证失败结果，以使所述客户端基于从对应的支付服务端获取的授权认证码向所述中心服务端发送授权登录请求；响应于所述授权登录请求，基于所述授权认证码建立与所述客户端之间的信任会话。
可选地，上述信任会话建立模块1302，其若所述合法性验证结果表征验证通过，则向所述客户端发送新的会话标识符，以使所述客户端基于所述新的会话标识符与所述中心服务端建立信任会话。
本说明书一个或多个实施例中的会话建立装置，接收客户端的保持登录请求，其中，该保持登录请求携带有本地预存的保持登录标识，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。响应于该保持登录请求，基于保持登录标识建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
需要说明的是，本说明书中关于会话建立装置的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话建立方法的实施，重复之处不再赘述。
对应上述图10描述的跨境支付方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种跨境支付装置，该装置设置于图1中的客户端，该装置用于执行图10描述的跨境支付方法，该装置包括：第一判断模块，其在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；第二判断模块，其若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；会话建立模块，其若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话；支付请求发送模块，其向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求并执行相应的跨境支付操作。
可选地，上述支付请求发送模块，其基于所述客户端所扫描的图形码的信息，生成跨境支付请求，并向所述中心服务端发送所述跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的所述图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
本说明书一个或多个实施例中的跨境支付装置，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率，进而提高中心服务端针对客户端的跨境支付请求的响应效率。
需要说明的是，本说明书中关于跨境支付装置的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话建立方法的实施，重复之处不再赘述。
对应上述图11描述的跨境支付方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种跨境支付装置，该装置设置于图1中的中心服务端，该装置用于执行图11描述的跨境支付方法，该装置包括：保持登录请求接收模块，其接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；信任会话建立模块，其响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话；跨境支付处理模块，其接收所述客户端发送的跨境支付请求，并执行相应的跨境支付操作。
可选地，上述跨境支付处理模块，其接收所述客户端基于其扫描的图形码的信息所生成的跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对 在第二区域内使用的所述图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
本说明书一个或多个实施例中的跨境支付装置，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率，进而提高中心服务端针对客户端的跨境支付请求的响应效率。
需要说明的是，本说明书中关于跨境支付装置的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话建立方法的实施，重复之处不再赘述。
对应上述图2至图8、以及图9描述的会话建立方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种会话建立系统，该系统包括：图1中的客户端和中心服务端；其中，所述客户端包括图12所示的会话建立装置，所述中心服务端包括图13所示的会话建立装置。
具体的，客户端在检测到用户针对支付应用的预设业务触发操作后，判断本地是否存在会话标识符sessionId；客户端若确定本地存在会话标识符sessionId，则向中心服务端发送携带有该会话标识符sessionId的跨境支付请求，以使中心服务端基于该会话标识符sessionId响应于客户端的跨境支付请求并向客户端发送相应的反馈指示；客户端若确定本地不存在会话标识符sessionId，则判断本地是否存在保持登录标识clientKey。
(1)针对本地存在保持登录标识clientKey的情况，客户端基于该保持登录标识clientKey，向中心服务端发送保持登录请求；中心服务端响应于客户端的保持登录请求，对该保持登录请求中携带的保持登录标识clientKey进行合法性验证；中心服务端若确定clientKey合法性验证通过，则向客户端返回一个新的会话标识符sessionId；客户端在接收到中心服务端返回的新的会话标识符sessionId后，基于该sessionId与中心服务端建立信任会话。
(2)针对本地不存在保持登录标识clientKey的情况，客户端基于支付应用对应的支付服务端所颁发的授权认证码，向中心服务端发送授权登录请求；中心服务端响应于客户端的授权登录请求，向支付应用对应的支付服务端请求对上述授权认证码进行合法性验证；中心服务端若接收到针对授权验证码的合法性验证通过结果，则向客户端返回一个新的会话标识符sessionId和保持登录标识clientKey；客户端在接收到新的会话标识符sessionId和保持登录标识clientKey后，基于该sessionId与中心服务端建立信任会话，以及存储该clientKey，其中，后续客户端可以基于该clientKey向中心服务端请求保持登录，以使客户端与中心服务端之间建立信任会话，即建立客户端的SDK与中心服务端的SAAS服务之间的信任会话。
本说明书一个或多个实施例中的会话建立系统，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
需要说明的是，本说明书中关于会话建立系统的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话建立方法的实施，重复之处不再赘述。
对应上述图10、以及图11描述的跨境支付方法，基于相同的技术构思，本说明书 一个或多个实施例还提供了一种跨境支付系统，该系统包括：图1中的客户端和中心服务端；其中，所述客户端包括图10所示的跨境支付方法对应的装置，所述中心服务端包括图11所示的跨境支付方法对应的装置。
具体的，客户端在检测到用户针对支付应用的预设业务触发操作后，判断本地是否存在会话标识符sessionId；客户端若确定本地存在会话标识符sessionId，则向中心服务端发送携带有该会话标识符sessionId的跨境支付请求，以使中心服务端基于该会话标识符sessionId响应于客户端的跨境支付请求并向客户端发送相应的反馈指示；客户端若确定本地不存在会话标识符sessionId，则判断本地是否存在保持登录标识clientKey。
(1)针对本地存在保持登录标识clientKey的情况，客户端基于该保持登录标识clientKey，向中心服务端发送保持登录请求；中心服务端响应于客户端的保持登录请求，对该保持登录请求中携带的保持登录标识clientKey进行合法性验证；中心服务端若确定clientKey合法性验证通过，则向客户端返回一个新的会话标识符sessionId；客户端在接收到中心服务端返回的新的会话标识符sessionId后，基于该sessionId与中心服务端建立信任会话。
(2)针对本地不存在保持登录标识clientKey的情况，客户端基于支付应用对应的支付服务端所颁发的授权认证码，向中心服务端发送授权登录请求；中心服务端响应于客户端的授权登录请求，向支付应用对应的支付服务端请求对上述授权认证码进行合法性验证；中心服务端若接收到针对授权验证码的合法性验证通过结果，则向客户端返回一个新的会话标识符sessionId和保持登录标识clientKey；客户端在接收到新的会话标识符sessionId和保持登录标识clientKey后，基于该sessionId与中心服务端建立信任会话，以及存储该clientKey，其中，后续客户端可以基于该clientKey向中心服务端请求保持登录，以使客户端与中心服务端之间建立信任会话，即建立客户端的SDK与中心服务端的SAAS服务之间的信任会话；客户端向中心服务端发送跨境支付请求，以使中心服务端响应于该跨境支付请求并执行相应的跨境支付操作。
本说明书一个或多个实施例中的跨境支付系统，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率，进而提高中心服务端针对客户端的跨境支付请求的响应效率。
需要说明的是，本说明书中关于跨境支付系统的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话建立方法的实施，重复之处不再赘述。
进一步地，对应上述图2至图8所示的方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种会话建立设备，该设备用于执行上述的会话建立方法，如图14所示。
会话建立设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器1401和存储器1402，存储器1402中可以存储有一个或一个以上存储应用程序或数据。其中，存储器1402可以是短暂存储或持久存储。存储在存储器1402的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对会话建立设备中的一系列计算机可执行指令。更进一步地，处理器1401可以设置为与存储器1402通信，在会话建立设备上执行存储器1402中的一系列计算机可执行指令。会话建立设备还可以包括一个或一个以上电源1403，一个或一个以上有线或无线网络接口1404，一个或一个以上输入输出接口1405，一个或一个以上键盘1406等。
在一个具体的实施例中，会话建立设备包括有存储器，以及一个或一个以上的程 序，其中一个或者一个以上程序存储于存储器中，且一个或者一个以上程序可以包括一个或一个以上模块，且每个模块可以包括对会话建立设备中的一系列计算机可执行指令，且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令：在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
可选地，计算机可执行指令在被执行时，在所述客户端与所述中心服务端之间完成信任会话建立之后，所述方法还包括：向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
可选地，计算机可执行指令在被执行时，所述基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话，包括：基于所述保持登录标识，生成用于发起保持登录的保持登录请求；向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求建立与所述客户端之间的信任会话。
可选地，计算机可执行指令在被执行时，所述基于所述保持登录标识，生成用于发起保持登录的保持登录请求，包括：确定登录请求生成因子，其中，所述登录请求生成因子包括：时间戳和随机因子中至少一项；利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于发起保持登录的保持登录请求。
可选地，计算机可执行指令在被执行时，在判断本地是否存在保持登录标识之后，还包括：若不存在保持登录标识，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并返回新的会话标识符和保持登录标识；其中，所述授权认证码是所述支付应用对应的支付服务端为所述客户端所颁发的；存储所述保持登录标识，并基于所述新的会话标识符，与所述中心服务端之间建立信任会话。
可选地，计算机可执行指令在被执行时，所述基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并返回新的会话标识符和保持登录标识，包括：基于所述客户端的授权认证码，生成用于发起授权登录的授权登录请求；向所述中心服务端发送所述授权登录请求，以使所述中心服务端基于所述授权认证码向所述支付服务端请求合法性验证、并在接收到针对所述授权认证码的合法性验证通过时返回新的会话标识符和保持登录标识。
可选地，计算机可执行指令在被执行时，在判断本地是否存在会话标识符之后，还包括：若存在会话标识符，则向所述中心服务端发送携带有所述会话标识符的跨境业务请求，以使所述中心服务端对所述会话标识符进行合法性验证；若接收到所述中心服务端针对所述会话标识符的验证失败结果，则执行判断本地是否存在保持登录标识的步骤。
可选地，计算机可执行指令在被执行时，所述向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求建立与所述客户端之间的信任会话，包括：向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求对所述保持登录标识进行合法性验证；若接收到所述中心服务端针对所述保持登录标识的验证失败结果，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并建立与所述客户端之间的信任会话。
可选地，计算机可执行指令在被执行时，在向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求对所述保持登录标识进行合法性验证之后，还包括：若接收到所述中心服务端返回新的会话标识符，则基于所述新的会话标识符，与所述中心服务端之间建立信任会话；其中，所述新的会话标识符是在针对所述保持登录标识的合法性验证通过时向所述客户端发送的。
本说明书一个或多个实施例中的会话建立设备，在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若客户端本地不存在会话标识符，则判断本地是否存在保持登录标识，其中，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。若客户端本地存在保持登录标识，则基于保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于该保持登录请求并建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
在另一个具体的实施例中，会话建立设备包括有存储器，以及一个或一个以上的程序，其中一个或者一个以上程序存储于存储器中，且一个或者一个以上程序可以包括一个或一个以上模块，且每个模块可以包括对会话建立设备中的一系列计算机可执行指令，且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令：接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
可选地，计算机可执行指令在被执行时，在所述客户端与所述中心服务端之间完成信任会话建立之后，所述方法还包括：接收所述客户端发送的跨境支付请求，并响应于所述跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
可选地，计算机可执行指令在被执行时，所述响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话，包括：对所述保持登录标识进行合法性验证，得到相应的合法性验证结果；基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话。
可选地，计算机可执行指令在被执行时，所述保持登录请求还携带有登录请求生 成因子；所述基于所述保持登录请求对所述保持登录标识进行合法性验证，得到相应的合法性验证结果，包括：获取与所述客户端对应的保持登录标识；利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于验证所述保持登录请求的登录验证信息；若所述保持登录请求与所述登录验证信息相匹配，则确定针对所述保持登录标识的合法性验证结果通过。
可选地，计算机可执行指令在被执行时，还包含用于进行以下计算机可执行指令：接收所述客户端的授权登录请求，其中，所述授权登录请求是所述客户端确定本地不存在保持登录标识所发送的，且所述授权登录请求携带有所述客户端的授权认证码，所述授权认证码是所述客户端上安装的支付应用对应的支付服务端为所述客户端所颁发的；响应于所述授权登录请求，基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，以使所述客户端存储所述保持登录标识、并基于所述新的会话标识符与所述中心服务端建立信任会话。
可选地，计算机可执行指令在被执行时，所述基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，包括：基于所述授权认证码，向与所述客户端所触发的支付应用对应的支付服务端请求授权认证码合法性验证；若接收到针对所述授权认证码的合法性验证通过结果，则向所述客户端返回新的会话标识符和保持登录标识。
可选地，计算机可执行指令在被执行时，在基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识之后，还包括：存储所述客户端的用户标识与所述新的会话标识符和所述保持登录标识之间的对应关系。
可选地，计算机可执行指令在被执行时，所述基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，包括：若所述合法性验证结果表征验证失败，则向所述客户端发送合法性验证失败结果，以使所述客户端基于从对应的支付服务端获取的授权认证码向所述中心服务端发送授权登录请求；响应于所述授权登录请求，基于所述授权认证码建立与所述客户端之间的信任会话。
可选地，计算机可执行指令在被执行时，所述基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，包括：若所述合法性验证结果表征验证通过，则向所述客户端发送新的会话标识符，以使所述客户端基于所述新的会话标识符与所述中心服务端建立信任会话。
本说明书一个或多个实施例中的会话建立设备，接收客户端的保持登录请求，其中，该保持登录请求携带有本地预存的保持登录标识，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。响应于该保持登录请求，基于保持登录标识建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
需要说明的是，本说明书中关于会话建立设备的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话建立方法的实施，重复之处不再赘述。
进一步地，对应上述图2至图8所示的方法，基于相同的技术构思，本说明书一个或多个实施例还提供了一种存储介质，用于存储计算机可执行指令，一种具体的实施例中，该存储介质可以为U盘、光盘、硬盘等，该存储介质存储的计算机可执行指令在被处理器执行时，能实现以下流程：在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授 权登录请求所发送的；若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，在所述客户端与所述中心服务端之间完成信任会话建立之后，所述方法还包括：向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话，包括：基于所述保持登录标识，生成用于发起保持登录的保持登录请求；向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求建立与所述客户端之间的信任会话。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述基于所述保持登录标识，生成用于发起保持登录的保持登录请求，包括：确定登录请求生成因子，其中，所述登录请求生成因子包括：时间戳和随机因子中至少一项；利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于发起保持登录的保持登录请求。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，在判断本地是否存在保持登录标识之后，还包括：若不存在保持登录标识，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并返回新的会话标识符和保持登录标识；其中，所述授权认证码是所述支付应用对应的支付服务端为所述客户端所颁发的；存储所述保持登录标识，并基于所述新的会话标识符，与所述中心服务端之间建立信任会话。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并返回新的会话标识符和保持登录标识，包括：基于所述客户端的授权认证码，生成用于发起授权登录的授权登录请求；向所述中心服务端发送所述授权登录请求，以使所述中心服务端基于所述授权认证码向所述支付服务端请求合法性验证、并在接收到针对所述授权认证码的合法性验证通过时返回新的会话标识符和保持登录标识。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，在判断本地是否存在会话标识符之后，还包括：若存在会话标识符，则向所述中心服务端发送携带有所述会话标识符的跨境业务请求，以使所述中心服务端对所述会话标识符进行合法性验证；若接收到所述中心服务端针对所述会话标识符的验证失败结果，则执行判断本地是否存在保持登录标识的步骤。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求建立与所述客户端之间的信任会话，包括：向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求对所述保持登录标识进行合法性验证；若接收到所述 中心服务端针对所述保持登录标识的验证失败结果，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并建立与所述客户端之间的信任会话。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，在向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求对所述保持登录标识进行合法性验证之后，还包括：若接收到所述中心服务端返回新的会话标识符，则基于所述新的会话标识符，与所述中心服务端之间建立信任会话；其中，所述新的会话标识符是在针对所述保持登录标识的合法性验证通过时向所述客户端发送的。
本说明书一个或多个实施例中的存储介质存储的计算机可执行指令在被处理器执行时，在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符。若客户端本地不存在会话标识符，则判断本地是否存在保持登录标识，其中，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。若客户端本地存在保持登录标识，则基于保持登录标识，向中心服务端发送保持登录请求，以使中心服务端响应于该保持登录请求并建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
在另一个具体的实施例中，该存储介质可以为U盘、光盘、硬盘等，该存储介质存储的计算机可执行指令在被处理器执行时，能实现以下流程：接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
本说明书一个或多个实施例中，针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，在所述客户端与所述中心服务端之间完成信任会话建立之后，所述方法还包括：接收所述客户端发送的跨境支付请求，并响应于所述跨境支付请求；其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话，包括：对所述保持登录标识进行合法性验证，得到相应的合法性验证结果；基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述保持登录请求还携带有登录请求生成因子；所述保持登录标识进行合法性验证，得到相应的合法性验证结果，包括：获取与所述客户端对应的保持登录标识；利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成登录验证信息；若所述保持登录请求与所述登录验证信息相匹配，则确定针对所述保持登录标识的合法性验证结果通过。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，还实现以下流 程：接收所述客户端的授权登录请求，其中，所述授权登录请求是所述客户端确定本地不存在保持登录标识所发送的，且所述授权登录请求携带有所述客户端的授权认证码，所述授权认证码是所述客户端上安装的支付应用对应的支付服务端为所述客户端所颁发的；响应于所述授权登录请求，基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，以使所述客户端存储所述保持登录标识、并基于所述新的会话标识符与所述中心服务端建立信任会话。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，包括：基于所述授权认证码，向与所述客户端所触发的支付应用对应的支付服务端请求授权认证码合法性验证；若接收到针对所述授权认证码的合法性验证通过结果，则向所述客户端返回新的会话标识符和保持登录标识。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，在基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识之后，还包括：存储所述客户端的用户标识与所述新的会话标识符和所述保持登录标识之间的对应关系。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，包括：若所述合法性验证结果表征验证失败，则向所述客户端发送合法性验证失败结果，以使所述客户端基于从对应的支付服务端获取的授权认证码向所述中心服务端发送授权登录请求；响应于所述授权登录请求，基于所述授权认证码建立与所述客户端之间的信任会话。
可选地，该存储介质存储的计算机可执行指令在被处理器执行时，所述基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，包括：若所述合法性验证结果表征验证通过，则向所述客户端发送新的会话标识符，以使所述客户端基于所述新的会话标识符与所述中心服务端建立信任会话。
本说明书一个或多个实施例中的存储介质存储的计算机可执行指令在被处理器执行时，接收客户端的保持登录请求，其中，该保持登录请求携带有本地预存的保持登录标识，该保持登录标识是中心服务端针对客户端的授权登录请求所发送的。响应于该保持登录请求，基于保持登录标识建立与客户端之间的信任会话。针对客户端与中心服务端之间建立信任会话的过程，在客户端请求授权登录阶段，由中心服务端同时向客户端发送相应的会话标识符和保持登录标识，以便后续客户端直接基于该保持登录标识请求保持登录，这样在保持登录标识有效期间无需执行授权登录的复杂交互流程，减少了授权登录的调用频次，从而简化了客户端与中心服务端之间建立信任会话的交互步骤，既能确保客户端能够安全登录中心服务端的SAAS服务，又能够提高客户端的安全登录效率。
需要说明的是，本说明书中关于存储介质的实施例与本说明书中关于会话建立方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的会话建立方法的实施，重复之处不再赘述。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的 硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HD Cal、JHDL(Java Hardware Description Language)、Lava、Lola、My HDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书一个或多个时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本说明书一个或多个的实施例可提供为方法、系统、或计算机程序产品。因此，本说明书一个或多个可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个是参照根据本说明书一个或多个实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定 方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本说明书一个或多个的实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本说明书一个或多个的实施例而已，并不用于限制本说明书一个或多个。对于本领域技术人员来说，本说明书一个或多个可以有各种更改和变化。凡在本说明书一个或多个的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书一个或多个的权利要求范围之内。

Claims (32)

  1. 一种会话建立方法，应用于客户端，所述客户端与中心服务端通信连接，所述方法包括：
    在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；
    若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
  2. 根据权利要求1所述的方法，其中，在所述客户端与所述中心服务端之间完成信任会话建立之后，所述方法还包括：
    向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求；
    其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
  3. 根据权利要求1所述的方法，其中，基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话，包括：
    基于所述保持登录标识，生成用于发起保持登录的保持登录请求；
    向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求建立与所述客户端之间的信任会话。
  4. 根据权利要求3所述的方法，其中，基于所述保持登录标识，生成用于发起保持登录的保持登录请求，包括：
    确定登录请求生成因子，其中，所述登录请求生成因子包括：时间戳和随机因子中至少一项；
    利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于发起保持登录的保持登录请求。
  5. 根据权利要求1所述的方法，其中，在判断本地是否存在保持登录标识之后，还包括：
    若不存在保持登录标识，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并返回新的会话标识符和保持登录标识；其中，所述授权认证码是所述支付应用对应的支付服务端为所述客户端所颁发的；
    存储所述保持登录标识，并基于所述新的会话标识符，与所述中心服务端之间建立信任会话。
  6. 根据权利要求5所述的方法，其中，基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并返回新的会话标识符和保持登录标识，包括：
    基于所述客户端的授权认证码，生成用于发起授权登录的授权登录请求；
    向所述中心服务端发送所述授权登录请求，以使所述中心服务端基于所述授权认证码向所述支付服务端请求合法性验证、并在接收到针对所述授权认证码的合法性验证通过时返回新的会话标识符和保持登录标识。
  7. 根据权利要求1所述的方法，其中，在判断本地是否存在会话标识符之后，还包括：
    若存在会话标识符，则向所述中心服务端发送携带有所述会话标识符的跨境业务请 求，以使所述中心服务端对所述会话标识符进行合法性验证；
    若接收到所述中心服务端针对所述会话标识符的验证失败结果，则执行判断本地是否存在保持登录标识的步骤。
  8. 根据权利要求3所述的方法，其中，向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求建立与所述客户端之间的信任会话，包括：
    向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求对所述保持登录标识进行合法性验证；
    若接收到所述中心服务端针对所述保持登录标识的验证失败结果，则基于所述客户端的授权认证码，向所述中心服务端发送授权登录请求，以使所述中心服务端响应于所述授权登录请求并建立与所述客户端之间的信任会话。
  9. 根据权利要求8所述的方法，其中，在向所述中心服务端发送所述保持登录请求，以使所述中心服务端基于所述保持登录请求对所述保持登录标识进行合法性验证之后，还包括：
    若接收到所述中心服务端返回新的会话标识符，则基于所述新的会话标识符，与所述中心服务端之间建立信任会话；
    其中，所述新的会话标识符是在针对所述保持登录标识的合法性验证通过时向所述客户端发送的。
  10. 一种会话建立方法，应用于中心服务端，所述中心服务端与客户端通信连接，所述方法包括：
    接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
  11. 根据权利要求10所述的方法，其中，在所述客户端与所述中心服务端之间完成信任会话建立之后，所述方法还包括：
    接收所述客户端发送的跨境支付请求，并响应于所述跨境支付请求；
    其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
  12. 根据权利要求10所述的方法，其中，响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话，包括：
    对所述保持登录标识进行合法性验证，得到相应的合法性验证结果；
    基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话。
  13. 根据权利要求12所述的方法，其中，保持登录请求还携带有登录请求生成因子；
    对所述保持登录标识进行合法性验证，得到相应的合法性验证结果，包括：
    获取与所述客户端对应的保持登录标识；
    利用预设生成算法，根据所述保持登录标识和所述登录请求生成因子，生成用于验证所述保持登录请求的登录验证信息；
    若所述保持登录请求与所述登录验证信息相匹配，则确定针对所述保持登录标识的合法性验证结果通过。
  14. 根据权利要求10所述的方法，其中，还包括：
    接收所述客户端的授权登录请求，其中，所述授权登录请求是所述客户端确定本地不存在保持登录标识所发送的，且所述授权登录请求携带有所述客户端的授权认证码，所述授权认证码是所述客户端上安装的支付应用对应的支付服务端为所述客户端所颁 发的；
    响应于所述授权登录请求，基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，以使所述客户端存储所述保持登录标识、并基于所述新的会话标识符与所述中心服务端建立信任会话。
  15. 根据权利要求14所述的方法，其中，基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识，包括：
    基于所述授权认证码，向与所述客户端所触发的支付应用对应的支付服务端请求授权认证码合法性验证；
    若接收到针对所述授权认证码的合法性验证通过结果，则向所述客户端返回新的会话标识符和保持登录标识。
  16. 根据权利要求14所述的方法，其中，在基于所述授权认证码向所述客户端返回新的会话标识符和保持登录标识之后，还包括：
    存储所述客户端的用户标识与所述新的会话标识符和所述保持登录标识之间的对应关系。
  17. 根据权利要求12所述的方法，其中，基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，包括：
    若所述合法性验证结果表征验证失败，则向所述客户端发送合法性验证失败结果，以使所述客户端基于从对应的支付服务端获取的授权认证码向所述中心服务端发送授权登录请求；
    响应于所述授权登录请求，基于所述授权认证码建立与所述客户端之间的信任会话。
  18. 根据权利要求12所述的方法，其中，基于针对所述保持登录标识的所述合法性验证结果，建立与所述客户端之间的信任会话，包括：
    若所述合法性验证结果表征验证通过，则向所述客户端发送新的会话标识符，以使所述客户端基于所述新的会话标识符与所述中心服务端建立信任会话。
  19. 一种跨境支付方法，应用于客户端，所述客户端与中心服务端通信连接，所述方法包括：
    在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；
    若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话；
    向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求并执行相应的跨境支付操作。
  20. 根据权利要求19所述的方法，其中，向所述中心服务端发送跨境支付请求，包括：
    基于所述客户端所扫描的图形码的信息，生成跨境支付请求，并向所述中心服务端发送所述跨境支付请求；
    其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的所述图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
  21. 一种跨境支付方法，应用于中心服务端，所述中心服务端与客户端通信连接，所述方法包括：
    接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话；
    接收所述客户端发送的跨境支付请求，并执行相应的跨境支付操作。
  22. 根据权利要求21所述的方法，其中，接收所述客户端发送的跨境支付请求，包括：
    接收所述客户端基于其扫描的图形码的信息所生成的跨境支付请求；
    其中，所述跨境支付请求是在第一区域内使用的所述客户端对在第二区域内使用的所述图形码执行扫码操作所生成的，所述第一区域与所述第二区域不同。
  23. 一种会话建立装置，设置于客户端，所述客户端与中心服务端通信连接，所述装置包括：
    第一判断模块，其在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；
    第二判断模块，其若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    会话建立模块，其若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
  24. 一种会话建立装置，设置于中心服务端，所述中心服务端与客户端通信连接，所述装置包括：
    保持登录请求接收模块，其接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    信任会话建立模块，其响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
  25. 一种跨境支付装置，设置于客户端，所述客户端与中心服务端通信连接，所述装置包括：
    第一判断模块，其在检测到针对所述客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；
    第二判断模块，其若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    会话建立模块，其若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话；
    支付请求发送模块，其向所述中心服务端发送跨境支付请求，以使所述中心服务端响应于所述跨境支付请求并执行相应的跨境支付操作。
  26. 一种跨境支付装置，设置于中心服务端，所述中心服务端与客户端通信连接，所述装置包括：
    保持登录请求接收模块，其接收所述客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是所述中心服务端针对所述客户端的授权登录请求所发送的；
    信任会话建立模块，其响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话；
    跨境支付处理模块，其接收所述客户端发送的跨境支付请求，并执行相应的跨境支付操作。
  27. 一种会话建立系统，包括：客户端和中心服务端，所述客户端与所述中心服务端通信连接；
    其中，所述客户端包括如权利要求23所述的会话建立装置，所述中心服务端包括如权利要求24所述的会话建立装置。
  28. 一种跨境支付系统，包括：客户端和中心服务端，所述客户端与所述中心服务端通信连接；
    其中，所述客户端包括如权利要求25所述的跨境支付装置，所述中心服务端包括如权利要求26所述的跨境支付装置。
  29. 一种会话建立设备，包括：
    处理器；以及
    被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
    在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；
    若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是中心服务端针对所述客户端的授权登录请求所发送的；
    若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
  30. 一种会话建立设备，包括：
    处理器；以及
    被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
    接收客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是中心服务端针对所述客户端的授权登录请求所发送的；
    响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
  31. 一种存储介质，用于存储计算机可执行指令，所述可执行指令在被处理器执行时实现以下方法：
    在检测到针对客户端上安装的支付应用的预设业务触发操作后，判断本地是否存在会话标识符；
    若不存在会话标识符，则判断本地是否存在保持登录标识，其中，所述保持登录标识是中心服务端针对所述客户端的授权登录请求所发送的；
    若存在保持登录标识，则基于所述保持登录标识，向所述中心服务端发送保持登录请求，以使所述中心服务端响应于所述保持登录请求并建立与所述客户端之间的信任会话。
  32. 一种存储介质，用于存储计算机可执行指令，所述可执行指令在被处理器执行时实现以下方法：
    接收客户端的保持登录请求，其中，所述保持登录请求携带有本地预存的保持登录标识，所述保持登录标识是中心服务端针对所述客户端的授权登录请求所发送的；
    响应于所述保持登录请求，基于所述保持登录标识建立与所述客户端之间的信任会话。
PCT/CN2020/142515 2020-01-19 2020-12-31 会话建立方法、跨境支付方法、装置及系统 WO2021143547A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010062162.3 2020-01-19
CN202010062162.3A CN111327675B (zh) 2020-01-19 2020-01-19 会话建立方法、跨境支付方法、装置及系统

Publications (1)

Publication Number Publication Date
WO2021143547A1 true WO2021143547A1 (zh) 2021-07-22

Family

ID=71170976

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/142515 WO2021143547A1 (zh) 2020-01-19 2020-12-31 会话建立方法、跨境支付方法、装置及系统

Country Status (3)

Country Link
CN (2) CN114945037A (zh)
TW (1) TW202130160A (zh)
WO (1) WO2021143547A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114945037A (zh) * 2020-01-19 2022-08-26 支付宝实验室(新加坡)有限公司 会话建立方法、跨境支付方法、装置及系统
CN114363398B (zh) * 2021-12-23 2024-03-01 上海数禾信息科技有限公司 会话安全处理方法、装置、计算机设备和存储介质
CN115695594B (zh) * 2023-01-03 2023-03-07 徐工汉云技术股份有限公司 物联网数据通信方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102378170A (zh) * 2010-08-27 2012-03-14 中国移动通信有限公司 一种鉴权及业务调用方法、装置和系统
CN102752298A (zh) * 2012-06-29 2012-10-24 华为技术有限公司 安全通信方法、终端、服务器及系统
US9712621B1 (en) * 2013-02-11 2017-07-18 Amazon Technologies, Inc. Information sharing endpoint
CN111327675A (zh) * 2020-01-19 2020-06-23 支付宝实验室(新加坡)有限公司 会话建立方法、跨境支付方法、装置及系统

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030140146A1 (en) * 2002-01-23 2003-07-24 Akers Willard Stephen Method and system for interconnecting a Web server with a wireless portable communications device
CN106612180B (zh) * 2015-10-26 2020-06-09 阿里巴巴集团控股有限公司 实现会话标识同步的方法及装置
US20180060865A1 (en) * 2016-08-23 2018-03-01 Venuenext, Inc. Retrieving payment information for a user from an authentication server for use in purchase requests to vendors
CN106548333A (zh) * 2016-11-14 2017-03-29 唐红祥 一种跨境互动式金融支付终端
CN111628971B (zh) * 2017-02-09 2022-09-13 创新先进技术有限公司 一种信任登录方法
CN111738729A (zh) * 2017-06-26 2020-10-02 创新先进技术有限公司 一种业务处理方法、设备及系统
CN107483418A (zh) * 2017-07-27 2017-12-15 阿里巴巴集团控股有限公司 登录处理方法、业务处理方法、装置及服务器
CN108764886A (zh) * 2018-04-10 2018-11-06 阿里巴巴集团控股有限公司 二维码图片获取方法、装置以及设备
CN109784890A (zh) * 2018-12-06 2019-05-21 中非电子商务有限公司 跨境支付的方法及系统
CN110197376A (zh) * 2019-06-03 2019-09-03 山东管理学院 一种跨境电商互联网金融移动支付方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102378170A (zh) * 2010-08-27 2012-03-14 中国移动通信有限公司 一种鉴权及业务调用方法、装置和系统
CN102752298A (zh) * 2012-06-29 2012-10-24 华为技术有限公司 安全通信方法、终端、服务器及系统
US9712621B1 (en) * 2013-02-11 2017-07-18 Amazon Technologies, Inc. Information sharing endpoint
CN111327675A (zh) * 2020-01-19 2020-06-23 支付宝实验室(新加坡)有限公司 会话建立方法、跨境支付方法、装置及系统

Also Published As

Publication number Publication date
CN114945037A (zh) 2022-08-26
TW202130160A (zh) 2021-08-01
CN111327675B (zh) 2022-05-17
CN111327675A (zh) 2020-06-23

Similar Documents

Publication Publication Date Title
WO2021143547A1 (zh) 会话建立方法、跨境支付方法、装置及系统
WO2021208744A1 (zh) 应用程序的授权登录
US10708053B2 (en) Coordinating access authorization across multiple systems at different mutual trust levels
US11438168B2 (en) Authentication token request with referred application instance public key
US11316702B2 (en) Verification-based service authorization
TWI706265B (zh) 第三方授權登錄方法及系統
CA2945703C (en) Systems, apparatus and methods for improved authentication
US10785021B1 (en) User account authentication
TW201909015A (zh) 登錄資訊處理方法及設備
KR100863204B1 (ko) 애플리케이션 크리덴셜을 제공하는 방법 및 장치
TWI761745B (zh) 基於銀行卡快捷支付簽約的使用者核驗方法及裝置
US20170171183A1 (en) Authentication of access request of a device and protecting confidential information
CN110768968A (zh) 基于可验证声明的授权方法、装置、设备及系统
TW201500957A (zh) 用於使用者身份認證的方法和裝置
US20170372310A1 (en) Secure key based trust chain among user devices
US20220303120A1 (en) Guaranteed encryptor authenticity
WO2019165875A1 (zh) 一种交易处理方法、服务器、客户端及系统
CN112313983A (zh) 使用伴随设备的用户认证
KR20190016084A (ko) 데이터 송신 방법, 데이터 송신기, 데이터 수신기, 및 시스템
US20220337431A1 (en) Privacy proofing of secure element generated certificates
WO2020025056A1 (zh) 安全认证方法、装置和系统，移动终端
CN105812313A (zh) 恢复会话的方法和服务器、生成会话凭证的方法和装置
WO2024051365A1 (zh) 一种离线身份验证的方法、装置、存储介质及电子设备
US20240129288A1 (en) Privacy-protection based verification
CN115525930A (zh) 信息转移方法、装置及相关设备

Legal Events

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

Ref document number: 20914628

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20914628

Country of ref document: EP

Kind code of ref document: A1