A method and system for third party payment interface key management

Abstract

The application provides a third-party payment interface key management method and system, the method is as follows: 1, storing an alias name as a key and a key as a value into a Redis cache; 2, organizing a plaintext string text before signing on an application system; 3, after a proxy forwarding system receives an order request, signing the string before signing according to a signing algorithm to obtain a signature value sign1; 4, adding the signature value sign1 to the tail of a third-party channel request interface address url by splicing a symbol "&"; 5, requesting the proxy forwarding system to verify; 6, calculating the signature value sign2 in the mode of step 3, and then returning the application system; 7, comparing the signature value sign2 calculated by the proxy forwarding system with the signature value sign1 in the received third-party payment notice, so that the key is ensured to be concealed.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of payment management, in particular to a third-party payment interface key management method and system. BACKGROUND

[0002] An application system needs to use a third-party assigned key to sign and verify a recharge notification to verify the legality of the recharge. During the development stage, developers need to use the key for debugging and testing to verify the function availability. However, after the project goes online, the developers may misuse the key to fake the recharge notification, resulting in actual false payment and ultimately causing the company loss. Currently, common solutions include replacing a new key after the project debugging is completed and goes online, setting a recharge notification IP white list, and using a third-party channel order state query. However, these measures have certain limitations, for example, the key may need to be used again for debugging in the second development stage, and replacing a new key may cause online system abnormalities; the recharge notification IP white list may cause the system to be mistakenly intercepted when a new IP is added to the channel; in addition, not all channels provide an order query interface, limiting the application range of the solution. Therefore, a developer needs to develop and debug the interface without knowing the plaintext key.

[0003] The application system generally refers to an application that needs to use the key. For example, a payment system needs to use the payment key of a third-party channel, and it is referred to as an application system. SUMMARY

[0004] To overcome the above problems, the purpose of the application is to provide a third-party payment interface key management method, which ensures the concealment of the key.

[0005] The application adopts the following scheme: a third-party payment interface key management method, the method comprising the following steps:

[0006] Step 1, a key administrator inputs a key alias name and fills in the key and saves; the alias name is taken as a key, and the key is taken as a value and stored in a Redis cache;

[0007] Step 2, a developer organizes a plaintext string text before signing on an application system, and puts the text, the key alias name, a third-party channel order interface address url, a signature algorithm type and a signature parameter name signName into an HTTP request header, and then requests a proxy forwarding system to place an order;

[0008] Step 3, after receiving the order request, the proxy forwarding system obtains the key from the Redis cache through the key alias name, and splices it to the text to obtain a complete signature pre-string; the signature pre-string is signed according to the signature algorithm to obtain a signature value sign1;

[0009] Step 4, the "&" and the signature value sign1 are spliced to the tail of the third-party channel request interface address url, and the request is sent, and the returned result is returned to the application system;

[0010] Step 5, after the application system receives the payment notification of the third-party channel, a plaintext string text before signing is organized according to the payment notification signing rules agreed by the third-party channel, and the text, the key alias name and the signature algorithm are all put into the HTTP request header, and then the proxy forwarding system is requested for verification;

[0011] Step 6, after receiving the verification request, the proxy forwarding system calculates the signature value sign2 according to the method of step 3, and then returns the application system;

[0012] Step 7, the application system compares the signature value sign2 calculated by the proxy forwarding system with the signature value sign1 in the payment notification received from the third channel, and if they are inconsistent, returns that the payment of the third channel fails, and if they are consistent, returns that the payment of the third channel succeeds.

[0013] Further, the signature algorithm adopts MD5 algorithm for processing.

[0014] Further, after sending the request in step 4, the returned result is returned to the application system without change, and the application system can determine whether the call is successful according to the returned result of the third-party channel order interface, and returns the payment address pay_url to the user for payment.

[0015] Further, the signature rule in step 5 is the agreed signature rule corresponding to each third-party interface, which is used to verify whether the request is legal; the application system organizes the pre-signing string according to the signature rule of the third-party channel, and then sends it to the request proxy forwarding system for verification.

[0016] The application provides a third-party payment interface key management system, which comprises an alias input module, a request header data generation module, a signature processing module, a request data generation module, a verification module, a signature value acquisition module and a comparison module.

[0017] The alias input module is used for a key administrator to input a key alias name name, fill in a key and save; the key alias name name is used as a key, and the key is stored in the Redis cache as a value;

[0018] The request header data generation module organizes the plaintext string text before signing by the developer on the application system, and puts the text, key alias name, third-party channel order interface address url, signature algorithm type and signature parameter name signName into the HTTP request header, and then requests the proxy forwarding system to forward the order;

[0019] The signature processing module obtains the key from the Redis cache through the key alias name after the proxy forwarding system receives the order request, and splices it to the text to obtain the complete pre-signing string; and signs the pre-signing string according to the signature algorithm to obtain the signature value sign1.

[0020] The request data generation module adds the signature value sign1 to the end of the third-party channel request interface address url by adding "&", sends the request, and returns the returned result to the application system;

[0021] The verification module organizes the plaintext string text before signing according to the payment notification signature rule agreed by the third-party channel after the application system receives the payment notification of the third-party channel, and puts the text, key alias name and signature algorithm into the HTTP request header, and then requests the proxy forwarding system to verify;

[0022] The signature value acquisition module calculates the signature value sign2 according to the signature processing module after the proxy forwarding system receives the verification request, and then returns the application system;

[0023] The comparison module compares the signature value sign2 calculated by the proxy forwarding system with the signature value sign1 in the payment notification of the third-party channel by the application system, and returns the payment failure of the third-party channel if they are inconsistent, and returns the payment success of the third-party channel if they are consistent.

[0024] Further, the signature algorithm adopts MD5 algorithm for processing.

[0025] Further, the request data generation module returns the returned result to the application system after sending the request, and the application system can determine whether the call is successful according to the return result of the third-party channel order interface, and returns the payment address pay_url to the user for payment.

[0026] Further, the signature rule in the verification module is the signature rule agreed by each third-party interface, which is used to verify whether the request is legal; the application system organizes the string before signing according to the signature rule of the third-party channel, and then sends it to the request proxy forwarding system for verification.

[0027] The application has the beneficial effects that: the plaintext string text before signing is organized on the application system, and the text, the key alias name, the third-party channel order interface address url, the signature algorithm type and the signature parameter name signName are all put into the HTTP request header, and then the order is requested to be forwarded by the proxy system; the key is obtained from the Redis cache through the key alias name, and is spliced to the text to obtain a complete pre-signing string; the pre-signing string is signed according to the signature algorithm to obtain a signature value sign1; the application system compares the signature value sign2 calculated by the proxy system with the signature value sign1 received in the third-party channel payment notification, so that the developer can develop and debug the third-party channel without knowing the plaintext key of the third-party interface; and the key is ensured to be concealed. BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 is a method flowchart of the application.

[0029] Figure 2 is a system principle block diagram of the application. DETAILED DESCRIPTION

[0030] The application will be further described below with reference to the drawings.

[0031] Referring to Figure 1 , the application provides a third-party payment interface key management method, which comprises the following steps:

[0032] Step 1: a key administrator inputs a key alias name name, fills in a key and saves; the key alias name name is taken as a key, and the key is taken as a value and stored into a Redis cache;

[0033] Step 2: a developer organizes a plaintext string text before signing on an application system, and puts the text, the key alias name name, a third-party channel order interface address url, a signature algorithm type and a signature parameter name signName into a HTTP request header, and then requests a proxy forwarding system to place an order;

[0034] Step 3: after receiving the order request, the proxy forwarding system obtains the key from the Redis cache through the key alias name, splices the key to the text to obtain a complete pre-signing string, and signs the pre-signing string according to the signature algorithm to obtain a signature value sign1;

[0035] Step 4: the signature value sign1 is spliced to the tail of the third-party channel request interface address url by adding “&”, the request is sent, and the returned result is returned to the application system;

[0036] Step 5, after the application system receives the payment notice of the third-party channel party, the application system organizes the plaintext string text before signature according to the signature notice signature rule of the third-party channel agreement, and puts the text, key alias name and signature algorithm into the HTTP request header, and then requests the proxy forwarding system to verify;

[0037] Step 6, after the proxy forwarding system receives the verification request, the proxy forwarding system calculates the signature value sign2 according to the method of step 3, and then returns the application system;

[0038] Step 7, the application system compares the signature value sign2 calculated by the proxy forwarding system with the signature value sign1 in the received third-party channel payment notice, if they are inconsistent, the application system returns the third-party channel payment failure, if they are consistent, the application system returns the third-party channel payment success.

[0039] The application will be further described in combination with a specific embodiment:

[0040] A third-party payment interface key management method, the method comprises the following steps:

[0041] Step 1, the key administrator inputs the alias name name in the key management background, fills in the key and saves. The key management system stores the alias name name as the key and the key as the value in the Redis cache.

[0042] Suppose that the application system needs to access a new third-party channel now, then the developer needs to use the key to call the interface, but the plaintext key only the key administrator has the right to know, the developer is not allowed to touch the plaintext key. The key administrator inputs the alias name name = new_pay in the key management background, fills in the plaintext key = 4C904AD359DCDBA, and the administrator clicks save, the key management system stores the alias name name as the key and the key as the value in the Redis cache.

[0043] Step 2, the developer organizes the plaintext string text before signature on the application system, and puts the text, key alias name, third-party channel order interface address url, signature algorithm type and signature parameter name signName into the HTTP request header, and then requests the proxy forwarding system to order.

[0044] Assume that the third-party channel order placement interface parameters include order amount money, order number orderno, and signature sign. Assume that the signature sign rule of the third-party order placement interface is that the plaintext string text is obtained after money+orderno+key, and then MD5 is calculated to obtain sign, and then the order placement interface request is performed. However, since the developer cannot see the plaintext key, the sign cannot be calculated, but the rules and parameters required by the third-party channel interface signature can be transmitted to the proxy forwarding system for request. Assume that money=10, orderno=pay20240427hwjsu, the plaintext string text before signing on the application system is 10pay20240427hwjsu, the third-party channel order placement interface address url=https: / / api.pay3.com / order / create, the signature algorithm type=MD5, the signature parameter name signName=sign, the key alias name=new_pay, and these information is placed in the agreed request header Head[X.Pay]={"name":"new_pay","text":"10pay20240427hwjsu","url":"https: / / api.pay3.com / order / create?money=10&orderno=p ay20240427hwjsu","type":"MD5","signName":"sign"}, and the proxy order placement interface https: / / my.api.com / proxy / create of the proxy forwarding system is requested for order placement.

[0045] Step 3, after receiving the order placement request, the proxy forwarding system obtains the key from Redis through the key alias name, and concatenates it to the text to obtain the complete signature pre-string. According to the signature algorithm type, the signature value sign1 is calculated.

[0046] After receiving the order placement request, the proxy forwarding system obtains the key=4C904AD359DCDBA from Redis through the key alias name=new_pay, and concatenates it to the text to obtain the complete signature pre-string text=10pay20240427hwjsu4C904AD359DCDBA. According to the signature algorithm type=MD5, the signature MD5 is calculated to obtain the signature value sign1=49F09A0D1F03F09747812525FEBAE464.

[0047] Step 4, the agent forwarding system concatenates the signature parameter name {signName} = {sign1} with & to the third-party channel request interface address url, and sends the request. The obtained return result is returned to the application system without change.

[0048] The agent forwarding system concatenates the signature parameter name {signName} = {sign1} with & to the third-party channel request interface address url, and sends the request. The obtained return result is returned to the application system without change.

[0049] Step 5, after the application system receives the payment notification from the channel, the application system organizes the plaintext string text before signing according to the payment notification signing rules agreed by the channel, and puts the text, key alias name and signature algorithm type into the request header, and then requests the agent forwarding system for verification. The signing rule is the agreed signing rule corresponding to each third-party interface, which is used to verify whether the request is legal; the application system organizes the string before signing according to the signing rule of the third-party channel, and then sends it to the request agent forwarding system for verification.

[0050] After the user successfully pays using the pay_url, the application system receives the payment notification callbackurl=https: / / www.myapp.com / pay / callback?code=success&money=10&sign=C636B9AA899A1CE1713C996D573D7E19 from the channel party. The application system needs to verify whether the payment notification is legal according to whether the sign1 is correct. According to the payment notification signature rule agreed by the channel, sign1=MD5(code+money+key), the application system verifies whether the sign1 is legal, but since the developers of the application system do not know the plaintext key, the plaintext string text=code+money=success10, the key alias name=new_pay, and the signature algorithm type=MD5 are organized before signing, and are put into the request header Head[X.Callback]={"name":"new_pay","text":"success10","type":"MD5"}, and then the verification interface https: / / my.api.com / proxy / callback of the request proxy forwarding system is requested for verification.

[0051] Step 6, after receiving the verification request, the proxy forwarding system calculates the signature value sign2 according to step 3, and then returns the application system.

[0052] After receiving the verification request, the proxy forwarding system synchronizes with step 3, obtains the key=4C904AD359DCDBA from Redis through the key alias name=new_pay, and splices it to the text to obtain the complete signature text string text=success104C904AD359DCDBA. According to the signature algorithm type=MD5, the signature MD5 is calculated to obtain the signature value sign2=C636B9AA899A1CE1713C996D573D7E19. The calculated sign2 is returned to the application system.

[0053] Step 7, the application system compares the signature value sign2 calculated by the proxy forwarding system with the signature value sign1 in the payment notification received from the third channel party. If they are inconsistent, the third channel party payment fails, and if they are consistent, the third channel party payment succeeds.

[0054] The application system compares the signature value sign2=C636B9AA899A1CE1713C996D573D7E19 calculated by the proxy forwarding system with the signature value sign1=C636B9AA899A1CE1713C996D573D7E19 in the received payment notice of the channel party, and returns the channel party as a failure if the values are inconsistent, and returns the channel party as a success if the values are consistent.

[0055] Referring to Figure 2 As shown in the drawings, the application provides a system for third-party payment interface key management, which comprises an alias input module, a request header data generation module, a signature processing module, a request data generation module, a verification module, a signature value acquisition module and a comparison module.

[0056] The alias input module is used for inputting a key alias name by a key administrator, filling in the key and saving the key; the key alias name is used as a key, and the key is stored in a Redis cache as a value.

[0057] The request header data generation module is used for organizing a plaintext string text before signature by a developer on an application system, and putting the text, the key alias name, a third-party channel order interface address url, a signature algorithm type and a signature parameter name signName into an HTTP request header, and then requesting a proxy forwarding system to place an order.

[0058] Assume that the third-party channel order interface parameters have order amount money, order number orderno, and signature sign. Assume that the signature sign rule of the third-party order interface is that the plaintext string text is obtained after money+orderno+key, and then MD5 is calculated to obtain sign, and then the order interface request is performed. However, since the developer cannot see the plaintext key, the sign cannot be calculated, but the rules and parameters required by the third-party channel interface signature can be transmitted to the proxy forwarding system for request. Assume that money=10, orderno=pay20240427hwjsu, the plaintext string text before signing on the application system is 10pay20240427hwjsu, the third-party channel order interface address url=https: / / api.pay3.com / order / create, the signature algorithm type=MD5, the signature parameter name signName=sign, the key alias name=new_pay, and these information is placed in the agreed request header Head[X.Pay]={"name":"new_pay","text":"10pay20240427hwjsu","url":"https: / / api.pay3.com / order / create?money=10&orderno=p ay20240427hwjsu","type":"MD5","signName":"sign"}, and the proxy order interface https: / / my.api.com / proxy / create of the proxy forwarding system is requested to place an order.

[0059] The signature processing module obtains the key from the Redis cache through the key alias name after the proxy forwarding system receives the order request, and splices it to the text to obtain a complete signature pre-string; the signature algorithm is used to sign the signature pre-string to obtain a signature value sign1; the signature algorithm uses MD5 algorithm for processing.

[0060] The request data generation module adds "&" to the signature value sign1 and splices it to the tail of the third-party channel request interface address url, sends the request, and returns the returned result to the application system;

[0061] The verification module organizes the plaintext string text before signature according to the payment notice signature rule agreed by the third party channel after the application system receives the payment notice of the third party channel, and puts the text, key alias name and signature algorithm into the HTTP request header, and then requests the proxy forwarding system to verify; the signature rule is the signature rule agreed by each third party interface, and the signature rule is used to check whether the request is legal; the application system organizes the string before signature according to the signature rule of the third party channel, and then sends it to the request proxy forwarding system for verification.

[0062] The signature value obtaining module calculates the signature value sign2 according to the signature processing module after the proxy forwarding system receives the verification request, and then returns the application system;

[0063] The comparison module compares the signature value sign2 calculated by the application system with the signature value sign1 in the payment notice of the third party channel, and returns the payment failure of the third party channel if they are inconsistent, and returns the payment success of the third party channel if they are consistent.

[0064] The request data generating module returns the returned result to the application system intact after sending the request, and the application system can determine whether the call is successful according to the return result of the third party channel order interface, and returns the payment address pay_url to the user for payment.

[0065] The signature rule in the verification module is the signature rule agreed by each third party interface, and the signature rule is used to check whether the request is legal; the application system organizes the string before signature according to the signature rule of the third party channel, and then sends it to the request proxy forwarding system for verification.

[0066] The above is only the preferred embodiment of the present application, and any changes and modifications made within the scope of the present application are also included in the scope of the present application.

Claims

1. A method for managing third-party payment interface keys, characterized in that: The method includes the following steps: Step 1: The key administrator enters the key alias "name" and fills in the key, then saves it; the key is used as the alias "name" and the value is stored in the Redis cache. Step 2: The developers organize the plaintext string "text" before signing on the application system, and put "text", key alias "name", third-party channel order interface address "url", signature algorithm type and signature parameter name "signName" into the HTTP request header, and then request the proxy to forward the system to place the order; Step 3: After receiving the order request, the proxy forwarding system retrieves the key from the Redis cache using the key alias name, and appends it to the text string to obtain the complete pre-signature string; then, it signs the pre-signature string according to the signature algorithm to obtain the signature value sign1. Step 4: Add the signature value sign1 to the end of the URL of the third-party channel request interface, send the request, and return the result to the application system. Step 5: After receiving the payment notification from the third-party channel, the application system organizes the plaintext string "text" before signing according to the payment notification signing rules agreed upon by the third-party channel, and puts "text", the key alias "name", and the signing algorithm into the HTTP request header, and then requests the proxy forwarding system to verify it; Step 6: After receiving the verification request, the proxy forwarding system calculates the signature value sign2 according to the method in step 3, and then returns it to the application system; Step 7: The application system compares the signature value sign2 calculated by the proxy forwarding system with the signature value sign1 in the payment notification received from the third-party channel. If they do not match, the system returns a payment failure message to the third-party channel; if they match, the system returns a payment success message to the third-party channel. In step 5, the signature rule is a signature rule agreed upon for each third-party interface. This signature rule is used to verify whether the request is legitimate. The application system organizes the string before signing according to the signature rule of the third-party channel, and then sends it to the request proxy forwarding system for verification.

2. The method for managing third-party payment interface keys according to claim 1, characterized in that: The signature algorithm uses the MD5 algorithm.

3. The method for managing third-party payment interface keys according to claim 1, characterized in that: After sending the request in step 4, the result is returned to the application system unchanged. The application system can determine whether the call was successful based on the return result of the third-party channel order interface, and return the payment address pay_url to the user for payment.

4. A system for managing third-party payment interface keys, characterized in that: The system includes: an alias input module, a request header data generation module, a signature processing module, a request data generation module, a verification module, a signature value acquisition module, and a comparison module; In the alias input module, the key administrator inputs the key alias "name" and fills in the key, then saves it; the alias "name" is used as the key and the key is used as the value to store the key in the Redis cache. The request header data generation module allows developers to organize a plaintext string (text) before signing on the application system, and put the text, key alias (name), third-party channel order interface address (url), signature algorithm type, and signature parameter name (signName) into the HTTP request header, and then request the proxy to forward the system to place the order. The signature processing module, after receiving the order request from the proxy forwarding system, retrieves the key from the Redis cache using the key alias name, concatenates it to text, and obtains the complete pre-signature string; then, it signs the pre-signature string according to the signature algorithm to obtain the signature value sign1. The request data generation module appends "&" plus the signature value sign1 to the end of the URL of the third-party channel request interface, sends the request, and returns the result to the application system. The verification module, after receiving the payment notification from the third-party channel through the application system, organizes the plaintext string "text" before signing according to the payment notification signing rules agreed upon by the third-party channel, and puts "text", the key alias "name", and the signing algorithm into the HTTP request header, and then requests the proxy forwarding system to perform verification; The signature value acquisition module receives the verification request through the proxy forwarding system, calculates the signature value sign2 according to the signature processing module, and then returns it to the application system. The comparison module compares the signature value sign2 calculated by the application system using the proxy forwarding system with the signature value sign1 in the payment notification received from the third channel party. If they do not match, it returns a payment failure message to the third channel party; if they match, it returns a payment success message to the third channel party. The signature rules in the verification module are the agreed-upon signature rules for each third-party interface. These signature rules are used to verify whether the request is legitimate. The application system organizes the string before signing according to the signature rules of the third-party channel, and then sends it to the request proxy forwarding system for verification.

5. The system for managing third-party payment interface keys according to claim 4, characterized in that: The signature algorithm uses the MD5 algorithm.

6. The system for managing third-party payment interface keys according to claim 4, characterized in that: After the request data generation module sends the request, it returns the result to the application system unchanged. The application system can determine whether the call was successful based on the return result of the third-party channel order interface, and then return the payment address pay_url to the user for payment.

Images