Methodology for conducting service operations between systems, service platforms, and target systems.

Abstract

Embodiments of the present application relate to a method for performing an inter-system service operation, a service platform, and a target system. After receiving a service request sent by a source system, a service platform reads an account of a target system according to an account of the source system and information about the target system that are comprised in the service request, and sends the service request and the account of the target system to the target system, so that the target system performs a service operation corresponding to the service request after the verification of the account of the target system succeeds, and returns a performing result. Therefore, both the performing efficiency of an inter-system service operation and the user experience can be improved.

Description

Method for Executing Cross-System Business Operations, Business Platform, and Target System This application claims the priority of a Chinese patent application with the application number 201510947116.0 and the invention title "Method for Executing Cross-System Business Operations, Business Platform, and Target System" filed on December 17, 2015. The entire content thereof is incorporated herein by reference. Technical Field This application relates to the field of computer technology, and in particular, to a method for executing cross-system business operations, a business platform, and a target system. Background Art In traditional technologies, when executing cross-system (site) business operations, the source system sends a business request to the business platform, and then the business platform forwards the business request to the target system. After receiving the above business request, the target system returns the address information of the target system to the source system through the business platform. Thus, the source system jumps to the login interface of the target system according to the above address information; the target system receives the account and password of the target system input by the user on the login interface, and after the account and password of the target system are verified, executes the business operation corresponding to the business request, and returns the execution result to the source system through the business platform. It can be seen from this that in the prior art, when jumping from the source system to the target system, it is necessary for the user to input the account and password of the target system, which affects the efficiency of executing business operations and thus brings a poor experience to the user. Summary of the Invention Embodiments of this application provide a method for executing cross-system business operations, a business platform, and a target system, which can improve the efficiency of executing cross-system business operations. In a first aspect, a method for executing cross-system business operations is provided. The method includes: The business platform receives a first business request sent by the source system, and the first business request includes the account of the source system and the information of the target system; According to the account of the source system and the information of the target system, read the account of the target system from a preset storage unit, and the preset storage unit is used to store the accounts and information of other systems bound to the account of the source system; Send the first business request and the account of the target system to the target system for the target system to execute the business operation corresponding to the first business request after the verification of the account of the target system is passed; Receive the first execution result returned by the target system and forward the first execution result to the source system. In a second aspect, a method for executing cross-system business operations is provided. The method includes: The target system receives a first service request sent by a service platform and the account of the target system; After the account of the target system passes the verification, perform the service operation corresponding to the first service request to obtain a first execution result; Return the first execution result to the service platform. In a third aspect, a service platform is provided, which includes: a receiving unit, a reading unit, and a sending unit; The receiving unit is configured to receive a first service request sent by a source system, and the first service request includes the account of the source system and information of a target system; The reading unit is configured to read the account of the target system from a preset storage unit according to the account of the source system received by the receiving unit and the information of the target system, and the preset storage unit is used to store the accounts and information of other systems bound to the account of the source system; The sending unit is configured to send the first service request and the account of the target system read by the reading unit to the target system, so that after the account of the target system passes the verification, the target system performs the service operation corresponding to the first service request; The receiving unit is further configured to receive the first execution result returned by the target system and forward the first execution result to the source system. In a fourth aspect, a target system is provided, which includes: a receiving unit, an execution unit, and a sending unit; The receiving unit is configured to receive a first service request sent by a service platform and the account of the target system; The execution unit is configured to perform the service operation corresponding to the first service request to obtain a first execution result after the account of the target system received by the receiving unit passes the verification; The sending unit is configured to return the first execution result to the service platform. For the cross-system service operation execution method, service platform, and target system provided in this application, when the service platform receives a service request sent by the source system, it reads the account of the target system according to the account of the source system and the information of the target system included in the service request, and sends the service request and the account of the target system to the target system, so that the target system performs the service operation corresponding to the service request after the account of the target system passes the verification and returns the execution result. It can be seen that in the embodiments of this application, the steps of receiving the account and password of the target system input by the user are omitted. Therefore, the efficiency of cross-system service operation execution can be improved, and the user experience can be enhanced. Description of the Drawings FIG. 1 is a flowchart of a cross-system business operation execution method provided by an embodiment of the present application; FIG. 2 is a flowchart of a cross-system business operation execution method provided by another embodiment of the present application; FIG. 3 is a schematic diagram of a business platform provided by still another embodiment of the present application; FIG. 4 is a schematic diagram of a target system provided by yet another embodiment of the present application. Detailed Embodiment To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Apparently, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the scope of protection of the present application. For ease of understanding of the embodiments of the present application, the following will further explain with specific examples with reference to the accompanying drawings. The examples do not constitute a limitation to the embodiments of the present application. The cross-system business operation execution method provided by the embodiments of the present application is applicable to scenarios where business operations are executed through two or more systems. For example, it is applicable to scenarios where a user's payment operation is executed through two payment systems. It should be noted that in the embodiments of the present application, taking the execution of a user's payment operation through two payment systems as an example (for example, the business request is a payment request), the method for executing other business operations except payment operations through two or more systems is similar, and the present application will not repeat it here. Among them, the above two payment systems can be the source system (INBOUND) and the target system (OUTBOUND) respectively. The source system and the target system are respectively used to identify different currencies. For example, the source system can be a payment system (such as the Jpay cashier desk) signed with the merchant website in Country A, which is used to identify XX currency; while the target system can be a payment system registered by users in Country B (such as the Alipay system), which is used to identify YY currency. It should be noted that both the above source system and the target system are bound to the business platform (such as the Alipay Global Clearing Network (Alipay Plus Global Net, GlobalNet)). The business platform is mainly used to uniformly provide interconnected payment acceptance, currency exchange, and fund settlement services, etc. for each payment system. It should be noted that after the source system is bound to the business platform, when the source system receives a payment request sent by a user and identifies the current payment operation as a cross-system payment operation, it forwards the above payment request to the business platform; after the business platform is bound to the target system, after the target system executes the corresponding payment operation according to the received payment request, it returns the execution result to the business platform, and then the business platform forwards the execution result to the source system. Specifically, when a user in Country B places an order for purchasing goods on a merchant website in Country A and selects the target system as the payment channel, the source system will identify the above order as a cross-system payment acceptance. That is, the source system sends a payment acceptance instruction to the target system through GlobalNet. After the payment is completed, GlobalNet clears the funds to the source system according to the clearing rules; while the target system receives the payment acceptance instruction from GlobalNet, deducts the payment acceptance amount from the designated account (the account of the target system) and clears the funds to GlobalNet according to the clearing rules. Figure 1 is a flowchart of a method for executing cross-system business operations provided by an embodiment of the present application. The execution subject of the method can be a device with processing capabilities: a server or a system or a device, such as a business platform. As shown in Figure 1, the method can specifically include: Step 110, the business platform receives a first business request sent by the source system, and the first business request includes the account of the source system and information about the target system. Here, the source system can be a payment system (such as the Jpay cashier desk) signed with the merchant website in Country A, which is used to identify XX currency; while the target system can be a payment system registered by users in Country B (such as the Alipay system), which is used to identify YY currency. In addition, the information about the target system can be the name of the target system, etc. The account used by the user in Country B to log in to the source system is called the account of the source system. Taking a business request as a payment request as an example, after a user in Country B selects and places an order for goods on a merchant website in Country A, the merchant website jumps to the source system with which it has signed a contract. The user can select a payment channel in the source system. Assuming that the payment channel input by the user received is the target system, the source system identifies this payment operation as a cross-system payment operation, that is, the source system sends a first business request to the business platform. Optionally, before performing step 110, the method of the embodiment of the present application may further include a step of storing the correspondence between the account of the source system and the account of the target system in the preset storage unit. Through this step, the business platform can read the account of the target system according to the account of the source system and the information of the target system, without the user inputting the account and password of the target system, thereby improving the execution efficiency of the payment operation and the user experience. The specific steps are as follows: Step 1101, receive a second business request sent by the source system, where the second business request includes the account of the source system and the information of the target system. This second business request may be sent when the source system first identifies that the payment channel selected by the user corresponding to the account of the source system is the target system. The second business request may also include the payment amount. Step 1102, according to the information of the target system, send the second business request to the target system to be used to load the login interface of the target system and to verify the account and password of the target system received from the login interface. Here, the account of the target system may be the account used by the user in Country B in the above example to log in to the target system. It should be noted that when the second business request also includes the payment amount, since the source system identifies XX currency and the target system identifies YY currency, the business platform may also convert the above payment amount according to the exchange rate between XX currency and YY currency to obtain the converted payment amount. That is, the second service request sent by the service platform to the target system may include the converted payment amount. After receiving the second service request, the target system may return the address information of the target system (e.g., URL address) to the source system through the service platform, so that the source system can jump to the login interface of the target system (i.e., load the login interface of the target system) according to the address information of the target system; the target system may receive the account and password of the target system input by the user through the login interface, and verify the received account and password of the target system. After the verification is passed, the target system may display an interface asking the user to select a payment tool and enter a payment password; after the received payment password is verified, the service operation corresponding to the second service request may be executed, e.g., deduct the converted payment amount from the account of the target system. Step 1103: Receive the second execution result returned by the target system after executing the service operation corresponding to the second service request when the verification is passed, where the second execution result includes the account of the target system. Optionally, the second execution result may further include result information indicating whether the service operation is executed successfully, e.g., it may include information indicating whether the deduction is successful. Step 1104: Store the corresponding relationship between the account of the source system and the account of the target system in the preset storage unit. That is, after receiving the account of the target system, the service platform may record the account of the source system, the information of the target system, and the corresponding relationship between the accounts of the target system received in step 1101 in the preset storage unit. In one example, the content of the preset storage unit may be as shown in Table 1. Table 1 In Table 1, the accounts and names of the target systems bound to the accounts of two source systems are stored at the same time. It can be understood that, based on the account of the source system and the name of the target system, an account of a target system can be uniquely read. Optionally, step 1104 may further include: Send the second execution result to the source system for the source system to obtain a message indicating the confirmation of the bound account, and return a storage instruction to the service system after obtaining the message indicating the confirmation of the bound account; According to the storage instruction, store the corresponding relationship between the account of the source system and the account of the target system in the preset storage unit. Specifically, when the business platform receives the second execution result sent by the target system, it sends the second execution result to the source system. After receiving the above second execution result, the source system can output a request asking whether to bind the account of the source system with the account of the target system, and receive the message of confirming the bound account input by the user, that is, receive the authorization instruction of the user. In one implementation, the request can be output in a page display manner. The page may include a "confirm" button. When the source system receives the click instruction of the "confirm" button, it is equivalent to receiving the authorization instruction of the user. After the source system obtains the message of confirming the bound account, it can send a storage instruction to the business platform. The storage instruction is used to instruct the business platform to load the setting page of the cross-system payment password. After receiving the cross-system payment password input by the user, the business platform encrypts and stores it locally to verify the cross-system payment password input by the subsequent user. Of course, in actual applications, the source system can pre-store the address information of the setting page of the cross-system payment password of the business platform. After obtaining the message of confirming the bound account, it jumps to the setting page of the cross-system payment password according to the address information. After receiving the cross-system payment password input by the user, the business platform encrypts and stores it locally to verify the cross-system payment password input by the subsequent user. After obtaining the cross-system payment password input by the user, the business platform can store the corresponding relationship between the account of the source system and the account of the target system in the preset storage unit. Optionally, after step 1104, the method may further include the following steps: Add identification information to the account of the target system, so that when the target system verifies the account of the target system again, it only verifies the account of the target system and does not need to verify the password. That is, assuming that the content of the preset storage unit is shown in Table 1, and assuming that the account of the target system included in the payment request received by the target system is "22", because "22" is the account bound with the account of the source system and the target system has added identification information to it, the target system only performs the corresponding payment operation after the account verification of the target system passes, and does not need to verify the password corresponding to this account again. Step 120, read the account of the target system from the preset storage unit according to the account of the source system and the information of the target system. The preset storage unit is used to store the accounts and information of other systems bound with the account of the source system. Other system accounts and information. For example, assume that the account of the source system included in the first service request is "11" and the name of the target system is "aa". Then, the account of the target system can be read as "22" from Table 1. That is, when the user corresponding to "11" logs in from the source system to the target system, the user does not need to enter "22" and the password again. Instead, the service platform directly reads "22" corresponding to "11" and carries the account of the target system in the payment request sent to the target system. Here, it should be noted that if the service platform cannot read the account and password of the target system, steps 1101 to 1104 are executed to store the corresponding relationship between the account of the source system and the account of the target system in the storage unit. Step 130: Send the first service request and the account of the target system to the target system, so that after the account of the target system is verified, the target system executes the service operation corresponding to the first service request. Optionally, after reading the account of the target system, the service platform can also verify whether to use the read account of the target system. Specifically, the service platform can output an inquiry request to the user on whether to use the read account of the target system. When receiving the information indicating confirmation to use the read account of the target system, the service platform receives the cross-system payment password input by the user, and when the received cross-system payment password input by the user is compared with the cross-system payment password pre-stored locally and is consistent (i.e., when the cross-system payment password verification is successful), the service platform sends the first service request and the account of the target system to the target system. In the foregoing example, the target system can receive the first service request and "22". Since "22" is the account pre-registered by the user in the target system, that is, "22" has been stored in the target system, the account verification of the target system passes. In addition, since the target system has added identification information to the account of the target system bound to the account of the source system in the preset storage unit, that is, there is no need to verify the password corresponding to the account of the target system, the target system only executes the service operation corresponding to the first service request after the account verification of the target system passes. For example, execute a payment operation, that is, deduct the converted payment amount from the account of the target system. In one example, the target system can transfer the converted payment amount deducted from the account of the target system to the temporary account of the service platform, and then the service platform transfers the corresponding payment amount to the account of the source system. Step 140: Receive the first execution result returned by the target system and forward the first execution result to the source system. For example, the service platform receives the first execution result after the target system executes the payment operation. The first execution result can include a message indicating whether the payment operation is executed successfully. After receiving the first execution result, the source system can jump back to the merchant system so that the user can select other goods. For the cross-system business operation execution method provided in this application, when the business platform receives a business request sent by the source system, it reads the account of the target system according to the account of the source system and the information of the target system included in the business request, and logs in to the target system according to the read account of the target system, so that the target system executes the business operation corresponding to the business request and returns the execution result. It can be seen that in the embodiments of this application, the steps of receiving the account and password of the target system input by the user are omitted. Therefore, the efficiency of cross-system business operation execution can be improved, and the user experience can be enhanced. FIG. 2 is a flowchart of a cross-system business operation execution method provided in another embodiment of this application. The execution subject of the method can be a device with processing capabilities: a server or a system or a device, such as the target system. As shown in FIG. 2, the method can specifically include: Step 210, the target system receives the first business request sent by the business platform and the account of the target system. Here, the target system can be a payment system registered by users in Country B (such as the Alipay system), which is used to identify the YY currency. The account used by users in Country B to log in to the target system is called the account of the target system. Taking the business request as a payment request as an example, after a user in Country B selects and places an order for goods on a merchant website in Country A, the merchant website jumps to the source system with which it has signed a contract; the user can select a payment channel in the source system. Assuming that the received payment channel input by the user is the target system, the source system identifies this payment operation as a cross-system payment operation, that is, the source system sends a first business request to the business platform. After receiving the first business request, the business platform forwards the first business request to the target system and can also send the account of the target system to the target system. The above-mentioned source system can be a payment system (such as the Jpay cashier desk) signed with the merchant website in Country A, which is used to identify the XX currency. The account used by users in Country B to log in to the source system is called the account of the source system. Among them, the account of the target system sent by the business platform to the target system can be read from a preset storage unit, that is, read from the preset storage unit according to the account of the source system and the information of the target system carried in the first business request received from the source system. The information of the target system can be the name of the target system, etc. The corresponding relationship between the account of the source system and the account of the target system in the preset storage unit can be established through the following steps: Step 2101, the target system loads the login interface of the target system according to the second business request received from the business platform. Here, the second service request may include the converted payment amount, which is obtained by the service platform through converting the above payment amount according to the exchange rate between currency XX and currency YY. After receiving the second service request, the target system may return the address information (such as the URL address) of the target system to the source system through the service platform, so that the source system can jump to the login interface of the target system (i.e., load the login interface of the target system). Step 2102: Obtain the account and password of the target system from the login interface, and verify the account and password of the target system. The target system may receive the account and password of the target system input by the user through the login interface, and verify the received account and password of the target system. Step 2103: After the verification of the account and password of the target system is passed, execute the service operation corresponding to the second service request to obtain a second execution result. After the verification is passed, the target system may display an interface asking the user to select a payment tool and enter a payment password; after the received payment password is verified, the service operation corresponding to the second service request may be executed, such as deducting the converted payment amount from the account of the target system. Step 2104: Return the second execution result to the service platform, where the second execution result includes the account of the target system, for the service platform to store the account of the target system. Optionally, the second execution result may further include result information on whether the service operation is successfully executed, such as information on whether the deduction is successful. That is, after receiving the account of the target system, the service platform may record the corresponding relationship between the received account of the source system, the information of the target system, and the account of the target system in a preset storage unit. In an example, the content of the preset storage unit may be as shown in Table 1. In Table 1, the accounts and names of the target systems bound to the accounts of two source systems are stored at the same time. It can be understood that according to the account of the source system and the name of the target system, an account of a target system can be uniquely read. Optionally, the specific way for the service platform to store the corresponding relationship between the account of the source system and the account of the target system in the preset storage unit may be: When the service platform receives the second execution result sent by the target system, it sends the second execution result to the source system. After receiving the second execution result, the source system can output a request asking whether to bind the account of the source system to the account of the target system, and receive the message of confirming the bound account input by the user, that is, receive the authorization instruction of the user. In one implementation, the request can be output in the form of a page display. The page can include a "confirm" button. When the source system receives the click instruction of the "confirm" button, it is equivalent to receiving the authorization instruction of the user. After the source system obtains the message of confirming the bound account, it can send a storage instruction to the service platform. The storage instruction is used to instruct the service platform to load the setting page of the cross-system payment password. After receiving the cross-system payment password input by the user, the service platform encrypts and stores it locally to verify the cross-system payment password input by the subsequent user. Of course, in practical applications, the source system can pre-store the address information of the setting page of the cross-system payment password of the service platform. When obtaining the message of confirming the bound account, it jumps to the setting page of the cross-system payment password according to the address information. After receiving the cross-system payment password input by the user, the service platform encrypts and stores it locally to verify the cross-system payment password input by the subsequent user. After obtaining the cross-system payment password input by the user, the service platform can store the corresponding relationship between the account of the source system and the account of the target system in the preset storage unit. Optionally, after the account and password of the target system are verified, the method further includes: Adding identification information to the account of the target system, so that when the target system verifies the account of the target system again, it only verifies the account of the target system and does not need to verify the password. That is, assuming that the content of the preset storage unit is shown in Table 1, and assuming that the account of the target system included in the payment request received by the target system is "22", because "22" is the account bound to the account of the source system and the target system has added identification information to it, the target system only executes the corresponding payment operation after the account of the target system is verified, and there is no need to verify the password corresponding to this account. Return to step 210. After the service platform reads the account of the target system, it can also verify whether to use the read account of the target system. Specifically, the service platform can output an inquiry request to the user asking whether to use the read account of the target system. When receiving the information indicating confirmation to use the read account of the target system, it receives the cross-system payment password input by the user, and when the received cross-system payment password input by the user is consistent with the cross-system payment password pre-stored locally (i.e., when the cross-system payment password verification is successful), it sends the first service request and the account of the target system to the target system. Step 220, after the account of the target system is verified, perform the service operation corresponding to the first service request to obtain the first execution result. In the foregoing example, the target system can receive the first service request and "22". Since "22" is the account pre-registered by the user in the target system, that is, "22" has been stored in the target system, the account verification of the target system passes. In addition, since the target system has added identification information to the account of the target system bound to the account of the source system in the preset storage unit, that is, there is no need to verify the password corresponding to the account of the target system, so the target system only performs the service operation corresponding to the first service request after the account verification of the target system passes to obtain the first execution result. For example, perform a payment operation, that is, deduct the converted payment amount from the account of the target system. Step 230, return the first execution result to the service platform. For example, the target system can return the first execution result to the service platform after performing the payment operation and obtaining the first execution result. The first execution result can include a message indicating whether the payment operation is successfully executed. After receiving the first execution result, the source system can jump back to the merchant system so that the user can select other goods. For the cross-system service operation execution method provided in this application, when the service platform receives the service request sent by the source system, it reads the account of the target system according to the account of the source system and the information of the target system included in the service request, and logs in to the target system according to the read account of the target system, so that the target system executes the service operation corresponding to the service request and returns the execution result. It can be seen that in the embodiments of this application, the steps of receiving the account and password of the target system input by the user are omitted. Therefore, the efficiency of cross-system service operation execution can be improved, and the user experience can be enhanced. Corresponding to the cross-system service operation execution method provided in the foregoing embodiment, an embodiment of this application further provides a service platform. As shown in Figure 3, the service platform includes: a receiving unit 301, a reading unit 302, and a sending unit 303. A receiving unit 301, configured to receive a first service request sent by a source system, where the first service request includes an account of the source system and information of a target system. A reading unit 302, configured to read an account of the target system from a preset storage unit according to the account of the source system and the information of the target system received by the receiving unit 301, where the preset storage unit is used to store accounts and information of other systems bound to the account of the source system. A sending unit 303, configured to send the first service request and the account of the target system read by the reading unit 302 to the target system, so that after the target system passes the verification of the account of the target system, the sending unit 303 executes a service operation corresponding to the first service request. The receiving unit 301 is further configured to receive a first execution result returned by the target system and forward the first execution result to the source system. Optionally, the service platform further includes: a saving unit 304. The receiving unit 301 is further configured to receive a second service request sent by the source system, where the second service request includes an account of the source system and information of the target system. The sending unit 303 is further configured to send the second service request to the target system according to the information of the target system received by the receiving unit 301, so as to load a login interface of the target system and verify an account and a password of the target system received from the login interface. The receiving unit 301 is further configured to receive a second execution result returned after the target system executes a service operation corresponding to the second service request when the verification is passed, where the second execution result includes an account of the target system. The saving unit 304 is configured to store a correspondence between an account of the source system and an account of the target system in the preset storage unit. Wherein, the saving unit 304 is specifically configured to: Send the second execution result to the source system, so that the source system obtains a message for indicating confirmation of a bound account, and after obtaining the message for indicating confirmation of the bound account, returns a storage instruction to the service system; According to the storage instruction, store a correspondence between an account of the source system and an account of the target system in the preset storage unit. Optionally, the service platform is applied to cross-system login during a payment process, and the service request is a payment request. The functions of the functional modules of the device in the embodiments of the present application can be implemented by the steps of the above method embodiments. Therefore, the specific working process of the device provided in the present application will not be repeated here. In the service platform provided by this application, the receiving unit 301 receives a first service request sent by the source system, and the first service request includes the account of the source system and the information of the target system; the reading unit 302 reads the account of the target system from a preset storage unit according to the account of the source system and the information of the target system, and the preset storage unit is used to store the accounts and information of other systems bound to the account of the source system; the sending unit 303 sends the first service request and the account of the target system to the target system, so that after the account of the target system is verified and passed by the target system, the service operation corresponding to the first service request is executed; the receiving unit 301 receives the first execution result returned by the target system and forwards the first execution result to the source system. Thereby, the efficiency of cross-system service operation execution can be improved, and the user experience can be enhanced. Corresponding to the cross-system service operation execution method provided by the above another embodiment, an embodiment of this application further provides a target system. As shown in FIG. 4, the target system includes: a receiving unit 401, an execution unit 402, and a sending unit 403. The receiving unit 401 is configured to receive a first service request sent by the service platform and the account of the target system. The execution unit 402 is configured to execute the service operation corresponding to the first service request after the account of the target system received by the receiving unit 401 is verified and passed, and obtain a first execution result. The sending unit 403 is configured to return the first execution result to the service platform. Optionally, the target system further includes: a loading unit 404 and an obtaining unit 405. The loading unit 404 is configured to load the login interface of the target system according to a second service request received from the service platform. The obtaining unit 405 is configured to obtain the account and password of the target system from the login interface loaded by the loading unit 404 and verify the account and password of the target system. The execution unit 402 is further configured to execute the service operation corresponding to the second service request after the account and password of the target system obtained by the obtaining unit 405 are verified and passed, and obtain a second execution result. The sending unit 403 is further configured to return the second execution result obtained by the execution unit 402 to the service platform. The second execution result includes the account of the target system, so that the service platform stores the account of the target system. Optionally, the target system further includes: an adding unit 406. An adding unit 406 is configured to add identification information to an account of the target system, so that when the target system verifies the account of the target system again, only the account of the target system is verified, and the password does not need to be verified. The functions of the functional modules of the device according to the embodiments of the present application can be implemented by the steps of the above method embodiments. Therefore, the specific working process of the device provided in the present application will not be described in detail here. The target system provided in the present application includes: a receiving unit 401 configured to receive a first service request and an account of the target system sent by a service platform; an execution unit 402 configured to execute a service operation corresponding to the first service request and obtain a first execution result after the account of the target system is verified; and a sending unit 403 configured to return the first execution result to the service platform. Thereby, the efficiency of cross-system service operation execution can be improved, and the user experience can be enhanced. Those skilled in the art should also be able to further realize that the objects and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application. The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented by hardware, software modules executed by a processor, or a combination of the two. The software modules can be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium well-known in the technical field. The above specific embodiments further detail the purpose, technical solution, and beneficial effects of the present application. It should be understood that the above is only the specific embodiments of the present application and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

Revised September 14, 2018. Claims 1. Methods for conducting intersystem service operations, which shall include: providing the service platform with the first service request submitted by the source system, whereby the first service request shall include the source system's account and information about the target system; retrieving the target system's account from a predefined storage unit based on the source system's account and information about the target system, whereby the predefined storage unit shall be configured to store the source system's account and information of another system linked to the source system's account; sending the first service request and the target system's account to the target system so that the target system can perform the service operation corresponding to the first service request after verifying the target system's account; and receiving the results of the first operation submitted by the target system and forwarding the results of the first operation to the source system. ++++++++++++++++++++ Page 1 of 4 Claims 1.The method for providing intersystem services consists of the following steps:

1. The service platform receives the first service request sent by the source system, which includes the source system account and information about the target system.

2. The target system account is retrieved from a predefined storage unit, which is configured to store the source system account and information about other systems associated with it.

3. The first service request and the target system account are sent to the target system, allowing the target system to provide the service requested after verifying the target system account and receiving the initial performance result returned by the target system. This initial performance result is then forwarded to the source system.The method under claim 1 consists of steps for storing the mapping relationship between the source system account and the target system account in a predefined storage unit, and the steps include: receiving a second service request sent by the source system, which includes the source system account and information about the target system; sending the second service request to the target system based on the information about the target system; loading the target system's login interface and verifying the target system's account information and password received from the login interface; receiving a second performance result, which is returned after the target system performs the service according to the second service request upon successful verification, and the second performance result includes the target system account; and storing the mapping relationship between the source system account and the target system account in a predefined storage unit. 3.The method under Claim 2, storing the mapping relationship between the source system account and the target system account in a predefined storage unit, involves sending a second performance result to the source system so that the source system receives a message indicating that the account needs to be bound and returns a data storage order to the service system after receiving the message indicating that the account needs to be bound. (Page 2 of 4, storing the mapping relationship between the source system account and the target system account in a predefined storage unit according to storage instructions 4.) The method under Claim 1 through 3, which applies to inter-system login between payment and service requests, is a payment request.

5. The method of performing inter-system service delivery, which consists of: receiving the initial service request and the target system account sent by the service platform; after verifying the target system account, performing the service corresponding to the initial service request to obtain the initial performance result; and returning the initial performance result to the service platform. 6.The method according to clause 5, before acceptance by the target system of the first service request and the target system account sent by the service platform, consists of: loading the login interface of the target system according to the second service request received from the service platform; obtaining the target system account and password information from the login interface and performing account and password verification. After the target system account and password have been verified, perform the service corresponding to the second service request to obtain the second performance result and return the second performance result to the service platform, which includes the target system account, so that the service platform stores the target system account.

7. The method according to claim clause 6, once the target system account and password have been verified, consists of: adding credentials to the target system account so that when verifying the target system account again, the target system will only verify the target system account without needing to verify the password. 8.The service platform consists of a receiving unit, a calling unit, and a sending unit. The receiving unit is configured to receive the first service request sent by the source system. This first service request contains the source system account and information about the target system. (Page 3 of 4) The retrieval unit is configured to retrieve the target system account from a predefined storage unit. Based on the source system account and information about the target system received by the receiving unit, the designated storage unit is configured to store the source system account and information of other systems associated with the source system account. The sending unit is configured to forward the first service request and the target system account retrieved by the calling unit to the target system so that the target system can perform the service according to the first service request after verifying the target system account; and the receiving unit is further configured to receive the first performance result returned by the target system and forward that first performance result to the source system. (9.)The service platform under claim 8, which includes additional storage units, the receiving unit is additionally configured to receive a second service request sent by the source system, which in turn contains the source system account and information about the target system. The sending unit is additionally configured to send the second service request to the target system based on the information about the target system received from the receiving unit, to load the target system's login interface, and to verify the target system's account and password information received from the login interface. The receiving unit is additionally configured to receive a second performance result, which is returned after the target system has performed the service according to the second service request upon successful verification, which in turn contains the target system account. The storage unit is configured to store the mapping relationship between the source system account and the target system account in a predefined storage unit. 10.The service platform under claim 9, whose data storage unit is specially configured to: send a second operational result to the source system so that the source system receives a message indicating that the account must be bound, and return a data storage command to the service system after receiving the message indicating that the account must be bound, and store the mapping relationship between the source system account and the target system account in the predefined data storage unit as per the storage instructions on page 4 of page 11. A service platform under one of claims 8 through 10, which the service platform applies to inter-system logins between payments and service requests as payment requests. 12.The target system consists of a receiving unit, an operating unit, and a transmitting unit. The receiving unit is configured to receive the initial service request and the target system account sent by the service platform. The operating unit is configured to, after verifying the target system account received from the receiving unit, perform the service corresponding to the initial service request to achieve the initial operation result. The transmitting unit is configured to return the initial operation result to the service platform.13.The target system, as per claim 12, comprises a load unit and a data storage unit. The load unit is configured to load the target system's login interface upon the second service request received from the service platform. The acquisition unit is configured to receive the target system's account and password information from the login interface loaded by the load unit and perform account and password verification. The execution unit is further configured, after the target system's account and password obtained by the acquisition unit have been verified, to perform the service corresponding to the second service request to achieve the second performance result. The transmission unit is further configured to return the second performance result performed by the acquisition unit to the service platform, which includes the target system account, so that the service platform stores the target system account. 14.The targeting system, as per claim 13, consists of a series of incremental units, which are configured to add credentials to the targeting system account so that when verifying the targeting system account again, the targeting system will only verify the targeting system account, without requiring password verification.