A mutual trust payment system

Abstract

The embodiment of the present invention relates to a mutual trust payment system, which includes: a client, a mutual trust authorization server and a payment server; the client is used to process the user's authorization token application and obtain the authorization token; it is also used to process the user's authorization payment application; the mutual trust authorization server is used to process the distribution of the authorization token; the payment server is used to provide each user with multiple bindable payment interfaces; it is also used to process the binding of the authorization token and the payment interface; it is also used to process the payment based on the authorization token. By using this system, the problem of frequent user registration can be avoided, the workload of the merchant platform for maintaining user information can be reduced, the payment efficiency can be improved, and the user's payment information can be protected from leakage.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to a mutual trust payment system. Background Art

[0002] With the popularization of Internet payment, online payment has brought people a faster payment experience. However, we have also found some problems in actual applications. For example, each merchant platform needs to register basic user information and bind its payment account information in a certain payment system. This repeated operation not only increases the workload of the merchant platform to maintain user information, but also increases the risk of leaking user payment information. Summary of the invention

[0003] The purpose of the present invention is to provide a mutual trust payment system in view of the defects of the prior art, which includes a client, a mutual trust authorization server and a payment server; by using this system, the problem of frequent user registration can be avoided, the workload of the merchant platform for maintaining user information can be reduced, the payment efficiency can be improved, and the user's payment information can be protected from leakage.

[0004] To achieve the above-mentioned purpose, an embodiment of the present invention provides a mutual-trust payment system, the system comprising: a client, a mutual-trust authorization server and a payment server;

[0005] The client is used to process the user's authorization token application and obtain the authorization token; it is also used to process the user's authorization payment application;

[0006] The mutual trust authorization server is used to process the distribution of authorization tokens;

[0007] The payment server is used to provide each user with multiple bindable payment interfaces; it is also used to process the binding of authorization tokens and payment interfaces; it is also used to process payments based on authorization tokens.

[0008] Preferably,

[0009] The client is specifically used to obtain first payment authorization request data carrying first user identification data and send it to the mutual trust authorization server; and receive a first user confirmation login page sent back from the mutual trust authorization server; use the first user confirmation login page to obtain first user login data and send it to the mutual trust authorization server; and receive first authorization token data sent back from the mutual trust authorization server; and bind the first authorization token data with the first user identification data.

[0010] Preferably,

[0011] The mutual trust authorization server is specifically used to receive the first payment authorization request data sent from the client; perform a first registered customer check on the first user identification data; if the check is successful, send the first user confirmation login page to the client; and receive the first user login data sent back from the client; perform a first user login verification on the first user login data; if the verification is successful, generate first authorization token data; and send the first payment interface binding instruction data carrying the first user identification data and the first authorization token data to the payment server; and receive the first binding result data sent back from the payment server; if the first binding result data is a successful binding, send the first authorization token data to the client.

[0012] Preferably,

[0013] The payment server is specifically used to receive the first payment interface binding instruction data sent from the mutual trust authorization server; and bind multiple first payment interfaces that are pre-bound to the first user identification data to the first authorization token data; if the binding is successful, set the first binding result data to binding success and send it to the mutual trust authorization server.

[0014] Preferably,

[0015] The client is specifically used to obtain the first order payment request data carrying the first authorization token data and the first order payment data, and send it to the payment server; and receive the first payment result data sent back from the payment server.

[0016] Preferably,

[0017] The payment server is specifically used to receive the first order payment request data sent from the client; call the first payment interface bound to the first authorization token data to perform payment processing on the first order payment data; and send the payment processing result data to the client as the first payment result data.

[0018] An embodiment of the present invention provides a mutual trust payment system, which includes a client, a mutual trust authorization server and a payment server; by using the system, the problem of frequent user registration can be avoided, the workload of the merchant platform for maintaining user information can be reduced, the payment efficiency can be improved, and the user's payment information can be protected from leakage. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 A schematic diagram of the structure of a mutual trust payment system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0021] The embodiment of the present invention provides a mutual trust payment system, such as Figure 1 As shown in a structural diagram of a mutual trust payment system provided by an embodiment of the present invention, the system includes: a client 101, a mutual trust authorization server 102 and a payment server 103.

[0022] The client 101 is used to process the user's authorization token application and obtain the authorization token.

[0023] In a specific implementation method provided by an embodiment of the present invention, the client 101 is specifically used to obtain first payment authorization request data carrying first user identification data, and send it to the mutual trust authorization server 102; and receive the first user confirmation login page sent back from the mutual trust authorization server 102; use the first user confirmation login page to obtain the first user login data, and send it to the mutual trust authorization server 102; and receive the first authorization token data sent back from the mutual trust authorization server 102; bind the first authorization token data with the first user identification data.

[0024] Here, when the user does not want to register a payment account on the merchant platform for payment on the client 101, he can initiate an authorization payment request through the client 101 and use the payment interface that the user has bound on the payment server 103 to make payment. This payment method is the authorized payment method. Before the user initiates the authorized payment through the client 101, the user needs to first initiate an authorization token application through the client 101, and can only make an authorized payment after obtaining the authorization token.

[0025] After the user confirms on the client 101 that he wants to initiate the authorization token application, the client 101 will obtain the user identification input by the user, that is, the first user identification data, which is the user identification data that has been registered on the mutual trust authorization server 102 and bound to the payment interface on the payment server 103; the first payment authorization request data is an instruction for initiating an authorization token application pre-agreed between the client 101 and the mutual trust authorization server 102, and the parameters of the instruction will carry the first user identification data as a mark of the identity of the applicant; after the client 101 sends the first payment authorization request data to the mutual trust authorization server 102, it will receive a first user confirmation login page sent back from the mutual trust authorization server 102, and the client 101 can use a web browser or other tools to open it; the page is used by the mutual trust authorization server 102 to confirm the authorization to the user. If the user confirms the authorization, he will enter his user ID on the mutual trust authorization server 102 on the page. After the client 101 obtains the first user login data, it sends it to the mutual trust authorization server 102; if the remote mutual trust authorization server 102 successfully verifies it, it will generate an authorization token, that is, the first authorization token data, at the remote end, and automatically complete the binding of the payment interface on the payment server 103, and then the client 101 will receive the first authorization token data sent back from the mutual trust authorization server 102; after receiving the authorization token, the client 101 locally binds it with the first user identification data, then each time the user wants to authorize payment with the user identity corresponding to the first user identification data, the client 101 will automatically obtain the first authorization token data to participate in the payment, at which time, the user does not need to register a payment account on the merchant platform, nor does he need to enter the user password on the mutual trust authorization server 102 back and forth, and can directly use the payment interface bound to the payment server 103 to make payment.

[0026] The mutual trust authorization server 102 is used to handle the distribution of authorization tokens.

[0027] In another specific implementation method provided by an embodiment of the present invention, the mutual trust authorization server 102 is specifically used to receive the first payment authorization request data sent from the client 101; perform the first registered customer verification on the first user identification data; if the verification is successful, send the first user confirmation login page to the client 101; and receive the first user login data sent back from the client 101; perform the first user login verification on the first user login data; if the verification is successful, generate the first authorization token data; and send the first payment interface binding instruction data carrying the first user identification data and the first authorization token data to the payment server 103; and receive the first binding result data sent back from the payment server 103; if the first binding result data is a successful binding, send the first authorization token data to the client 101.

[0028] Here, after receiving the first payment authorization request data sent by the client 101, the mutual trust authorization server 102 will extract the first user identification data therefrom and perform a first registered customer verification on it; when processing the first registered customer verification, the mutual trust authorization server 102 will query the registered user database. If the first user identification data already exists therein, the first registered customer verification is successful, indicating that the user who currently initiates the payment authorization request is a registered user of this payment platform; after the first registered customer verification is successful, the mutual trust authorization server 102 pushes the first user confirmation login page to the client 101 for the user to confirm again and enter the login information; after the remote client 101 obtains the user's confirmation and login information, that is, the first user login data, it will send it to the mutual trust authorization server 102; after receiving the first user login data, the mutual trust authorization server 102 continues to query the registered user database, obtains the password corresponding to the first user identification data and compares it with the first user login data. If the comparison is consistent, the first user login is successful. The verification is successful; then, the mutual trust authorization server 102 generates a unique serial code according to the dynamic token generation method, which is commonly a combination of a timestamp and a random number. The serial code is the first authorization token data; after generating the first authorization token data, the mutual trust authorization server 102 needs to automatically bind it to the user's original payment interface on the payment server 103 for the user, so that the user can then directly call it through the authorization token; the first payment interface binding instruction data is the binding command sent by the mutual trust authorization server 102 to the payment server 103, and its command parameters carry the first user identification data reflecting the user's identity and the first authorization token data to be bound to the user; after the payment server 103 completes the binding of the payment interface, the mutual trust authorization server 102 will receive the first binding result data sent back by it. If the data is a successful binding, it means that all operations of the server on the authorization token have been successfully completed, and the mutual trust authorization server 102 will return the first authorization token data to the client 101.

[0029] The payment server 103 is used to provide each user with multiple bindable payment interfaces.

[0030] Here, the payment server 103 and the mutual trust authorization server 102 form a platform backend for authorized payment. The registration information and login information of all users of the payment platform are stored on the mutual trust authorization server 102. The mutual trust authorization server 102 is responsible for handling user login matters and authorization token distribution matters; the payment server 103 only provides a payment interface and the binding association between the payment interface and the user; the user needs to complete the login on the mutual trust authorization server 102 or obtain the authorization token distributed by it before choosing the payment interface on the payment server 103 for use.

[0031] The payment server 103 is also used to process the binding of the authorization token and the payment interface.

[0032] In another specific implementation method provided by an embodiment of the present invention, the payment server 103 is specifically used to receive the first payment interface binding instruction data sent from the mutual trust authorization server 102; and bind multiple first payment interfaces that are pre-bound to the first user identification data to the first authorization token data; if the binding is successful, set the first binding result data to binding success, and send it to the mutual trust authorization server 102.

[0033] Here, the payment server 103 receives the first payment interface binding instruction data sent by the mutual trust authorization server 102, and extracts the first user identification data and the first authorization token data therefrom; if the user has previously bound a payment interface to the payment server 103, then the payment server 103 will add an authorization usage object, that is, the first authorization token data, to all payment interfaces bound to it. After adding this object, the user does not have to complete a login every time to use the payment interface, and the payment server 103 does not have to query the user login status from the mutual trust authorization server 102 every time it receives a payment request from the user, and the mutual trust authorization server 102 and the payment server 103 do not have to frequently synchronize the user login status.

[0034] The client 101 is also used to process the user's authorization payment application.

[0035] In another specific implementation method provided by an embodiment of the present invention, the client 101 is specifically used to obtain first order payment request data carrying first authorization token data and first order payment data, and send it to the payment server 103; and receive first payment result data sent back from the payment server 103.

[0036] Here, after the user completes the authorization token application through the client 101, the user can initiate an authorization payment request through the client 101; specifically, the client 101 packages the first order payment data and the first authorization token data generated on the merchant platform together, generates the first order payment request data, and sends it to the payment server 103; the first order payment data must at least include the merchant account information, order amount information, payment channel information and other data used to initiate the payment interface for payment; after the payment server 103 completes the payment, the client 101 will receive the first payment result data related to the payment result.

[0037] The payment server 103 is also used to process payments based on authorization tokens.

[0038] In another specific implementation method provided by an embodiment of the present invention, the payment server 103 is specifically used to receive the first order payment request data sent from the client 101; call the first payment interface bound to the first authorization token data to perform payment processing on the first order payment data; and send the payment processing result data as the first payment result data to the client 101.

[0039] Here, after receiving the first order payment request data sent from the client 101, the payment server 103 extracts the first order payment data and the first authorization token data therefrom; if the first authorization token data exists and is not empty, the payment server 103 searches for the payment interface related thereto in the local associated database, and after finding multiple bound payment interfaces, selects the interface specifically used for payment this time according to the payment channel information in the first order payment data, and makes payment to the merchant account information through the interface, and the payment amount is the same as the order amount information; after the payment interface completes the payment, it will return a payment processing result data, that is, the first payment result data, and the payment server 103 will send it back to the client 101 to inform the user whether the payment is completed.

[0040] An embodiment of the present invention provides a mutual trust payment system, which includes a client, a mutual trust authorization server and a payment server; by using the system, the problem of frequent user registration can be avoided, the workload of the merchant platform for maintaining user information can be reduced, the payment efficiency can be improved, and the user's payment information can be protected from leakage.

[0041] The professionals should further realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to the function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0042] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0043] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A mutual trust payment system, characterized in that: The system comprises: a client, a mutual trust authorization server and a payment server; The client is used to process the user's authorization token application and obtain the authorization token; it is also used to process the user's authorization payment application; The mutual trust authorization server is used to process the distribution of authorization tokens; The payment server is used to provide each user with multiple bindable payment interfaces; it is also used to process the binding of the authorization token and the payment interface; it is also used to process the payment based on the authorization token; The client is specifically used to obtain first payment authorization request data carrying first user identification data, and send it to the mutual trust authorization server; and receive a first user confirmation login page sent back from the mutual trust authorization server; use the first user confirmation login page to obtain first user login data, and send it to the mutual trust authorization server; and receive first authorization token data sent back from the mutual trust authorization server; bind the first authorization token data with the first user identification data; The client is specifically used to obtain the first order payment request data carrying the first authorization token data and the first order payment data, and send it to the payment server; and receive the first payment result data sent back from the payment server; The payment server is specifically used to receive the first order payment request data sent from the client; call the first payment interface bound to the first authorization token data to perform payment processing on the first order payment data; and send the payment processing result data as the first payment result data to the client; The first order payment data includes merchant account information, order amount information, and payment channel information; The payment server is specifically used to, when performing the payment processing, if the first authorization token data is not empty, locally search for multiple first payment interfaces related thereto, and after finding the multiple first payment interfaces, select the first payment interface for this time according to the payment channel information, and pay the merchant account information through the first payment interface for this time, the payment amount is the same as the order amount information, and receive the payment processing result data returned by the first payment interface for this time.

2. The mutual trust payment system according to claim 1, characterized in that: The mutual trust authorization server is specifically used to receive the first payment authorization request data sent from the client; perform a first registered customer verification on the first user identification data; if the verification is successful, send the first user confirmation login page to the client; and receive the first user login data sent back from the client; Performing first user login verification on the first user login data; If the verification is successful, the first authorization token data is generated; and the first payment interface binding instruction data carrying the first user identification data and the first authorization token data is sent to the payment server; and the first binding result data sent back from the payment server is received; if the first binding result data is a successful binding, the first authorization token data is sent to the client.

3. The mutual trust payment system according to claim 2, characterized in that: The payment server is specifically used to receive the first payment interface binding instruction data sent from the mutual trust authorization server; and bind a plurality of first payment interfaces pre-bound to the first user identification data to the first authorization token data; If the binding is successful, the first binding result data is set as binding success and sent to the mutual trust authorization server.

Images