文档中心 | 一键联接，全心服务

更新日期：2023年 03月 08日QuickGameSDK Server Access Document

<h3 style="white-space:normal;"> I. Brief description </h3> 1. This document is intended for game server developers who access and use the SDK users and payment systems. 2. The SDK uses UTF8 encoding when communicating. 3. Double-issue communication, if there is a sign field, the signature must be verified. <h3 style="white-space:normal;"> Ⅱ. Interface list </h3> <h4 style="white-space:normal;"> 1. Verify user information interface </h4> This interface is for iOS and Android platforms. H5 games do not need to call this interface 1.1. Interface purpose After the game client gets the uid from the SDK login callback, in order to prevent the user from tampering with the client and forging the user uid marker so as to log into other people's accounts, the game client should pass this information to the game server. The game server calls this interface to verify the authenticity of the uid to the SDK. If the uid passes the verification, the user will be allowed to log in, if not, the user will be denied the authorization to log in. 1.2. Interface address http://quickgame.sdk.quicksdk.net/webapi/checkUserInfo 1.3. Request method GET/POST 1.4. Parameter List <table cellpadding="2" cellspacing="0" border="1" bordercolor="#000000" style="width:1009px;"> <tbody> <tr> <td> Parameter </td> <td> Necessary </td> <td> Description </td> </tr> <tr> <td> uid </td> <td> must </td> <td> be passed The uid obtained from the client login callback </td> </tr> <tr> <td> token </td> <td> must </td> <td> be passed The token obtained from the client login callback, please note that the length of the token should not be truncated </td> </tr> </tbody> </table> 1.5. Return field The interface will return a JSON formatted string Example 1  {"status":false,"message":"tokenUidError"} Example 2  {"status":true,"message":""} <table cellpadding="2" cellspacing="0" border="1" bordercolor="#000000" style="width:1009px;"> <tbody> <tr> <td> Parameters </td> <td> Type </td> <td> Necessary </td> <td> Description </td> </tr> <tr> <td> status </td> <td> bool </td> <td> must have </td> <td> Interface validation status, true if validated, false otherwise. </td> </tr> <tr> <td> message </td> <td> string </td> <td> must have </td> <td> If status is false, message has a value and is an error message. </td> </tr> <tr> <td> data </td> <td> object </td> <td> must have </td> <td> The data field is available only when status is true, it is user information, the object contains the following fields. uid: user uid isGuest: whether it is a guest account, 1 yes, 0 no. age: the age of the user, if the user has been authenticated to return the authenticated age, not authenticated to return 0 </td> </tr> </tbody> </table> 1.6. Request example http://quickgame.sdk.quicksdk.net/webapi/checkUserInfo?token=@171@174@188@127@182@163@148@179@166@168@132@179@165@222@169@116@109@166@96@212@152@156@116@121@106@139@170@154@203@134@124@118@108@164@205@126@173@151@172@169@169@140@158@215@138@153@164@136@160@162@154@197@114@212@159@143@126@125@154@179@168@151@135@155@121@148@215@146@181@100@158@219@161@112@106@184@108@189@121@129@120@158@141@186@129@177@169@140@105@136@128@176@205@124@124@166@163@179@213@151@175@124@185@140@155@124@171@160&uid=523 <h4 style="white-space:normal;"> 2. Issuing props interface </h4> 2.1. Interface purpose After the player finishes topping up, SDK will POST data to the shipping address provided by the game according to this interface protocol (referred to as sending notification), the game shall verify the relevant information and send props to the player after receiving the data from SDK POST. a) The game should verify the signature data according to the algorithm in Section 2.4.2 below to determine whether the request is legal. b) The game shall ship the props with the amount in the notification. c) The game shall determine whether the props are issued repeatedly, and if they have been issued, they cannot be issued again. d) Return SUCCESS after successful processing these 7 letters SDK will no longer notify, otherwise SDK will continue to notify within a period. 2.2. Interface address Issuing props address provided by the game, the SDK will initiate a POST request to this address. 2.3. Request method POST 2.4. POST parameter list SDK will POST 3 parameters to the game server：nt_data and sign and md5Sign All parameters are encoded ciphertext. Use the callbackkey obtained from the backend to decode the ciphertext nt_data is decoded (see the provided demo for decoding method) then it is an xml string For example： <pre class="brush:js;toolbar:false"><?xml version="1.0" encoding="UTF-8" standalone="no"?> <quick_message> <message> <uid>50848343</uid> <login_name>GG366822889</login_name> <out_order_no>13420170114150053861611313</out_order_no> <order_no>0720170114150059110833</order_no> <pay_time>2017-01-14 15:01:17</pay_time> <amount>0.01</amount> <status>0</status> <extras_params>13420170114150053861611313</extras_params> </message> </quick_message></pre> The meanings of the fields are as follows: <table cellpadding="2" cellspacing="0" border="1" bordercolor="#000000" style="width:1009px;"> <tbody> <tr> <td> Parameter </td> <td> Necessary </td> <td> Description </td> </tr> <tr> <td> uid </td> <td> must be passed </td> <td> The uid of the user who purchased the prop </td> </tr> <tr> <td> login_name </td> <td> must have </td> <td> User username of the purchased item </td> </tr> <tr> <td> out_order_no </td> <td> Can be empty </td> <td> The game order number passed when the game order was placed, returned as is </td> </tr> <tr> <td> order_no </td> <td> must have </td> <td> SDK unique order number </td> </tr> <tr> <td> pay_time </td> <td> must have </td> <td> the user payment time, such as 2017-02-06 14:22:32 </td> </tr> <tr> <td> amount </td> <td> must have </td> <td> the amount paid by the user </td> </tr> <tr> <td> extras_params </td> <td> must have </td> <td> the parameters passed through when the client placed the order, return as is </td> </tr> </tbody> </table> 2.4.1 CP should determine whether the props have been sent.  2.4.2 CP should determine whether the signature is consistent. Judgment method for CP to calculate the local signature localSign = md5(nt_data + sign + md5Key) Compare the local calculation result with the md5Sign in the notification is consistent. Failure to match should return failure. Note: The original text of nt_data, sign, and md5Key are directly spliced without adding splice characters and without decoding nt_data. 2.4.3 CP other judgment logic. 2.4.4 After processing is completed. a)If you want the SDK to continue to notify you, return any non-SUCCESS characters. b)When the processing is finished, the order ends, then SUCCESS is returned and SDK will not notify again. <h4 style="white-space:normal;"> 3. Get the list of player game characters (optional connection) </h4> 3.1. Interface purpose In the public web recharge platform players log in to their accounts to select a list of game roles. Players select a role and then recharge to that role. 3.2. Interface address The address is provided by the game, and the SDK will initiate a POST request to this address 3.3. Interface address POST 3.4. POST parameter list <table cellpadding="2" cellspacing="0" border="1" bordercolor="#000000" style="width:1009px;"> <tbody> <tr> <td> Parameter </td> <td> Necessary </td> <td> Description </td> </tr> <tr> <td> uid </td> <td> must have </td> <td> User SDK account uid </td> </tr> <tr> <td> username </td> <td> must have </td> <td> User SDK account name </td> </tr> <tr> <td> productCode </td> <td> must have </td> <td> SDK productCode </td> </tr> <tr> <td> sign </td> <td> must have </td> <td> Signature value, the game should be compared with this value after local calculation according to the signature convention. </td> </tr> </tbody> </table> 3.5. Return field description The game address returns the list of player's role information after receiving the SDK request, the data format is json, the return fields are as follows. <table cellpadding="2" cellspacing="0" border="1" bordercolor="#000000" style="width:1009px;"> <tbody> <tr> <td> Parameter </td> <td> Necessary </td> <td> Description </td> </tr> <tr> <td> code </td> <td> must have </td> <td> 200： the request is successful must have Each subset contains the following fields </td> </tr> <tr> <td> data </td> <td> must have </td> <td> Each subset contains the following fields. serverId: ID of the zone serverName: name of the zone roleId: role ID roleName: role name roleLevel: role level </td> </tr> </tbody> </table> Tip: Since the orders paid by the public web page have not been placed by the game, the notification shipping interface cannot get the specific order number of the game. At this time, the game can get the information of the extras_params parameter of the SDK notification callback to issue props to the specific player role. extras_params returns the format of "zone ID|@|role ID|@|commodity ID". 3.6. Signature algorithm When communicating, the SDK will attach the sign field to the request. The game removes the sign field from the received POST parameters and sorts them in ascending order by first letter. All the sorted key-value pairs are spliced in the format of key1=val1&key2=val2&key3=val3&. Splice the callbackKey of the SDK backend product after the characters spliced in step 2, then the format at this point is key1=val1&key2=val2&key3=val3&callbackKey The string processed in step 3 will be md5 encoded to get 32-bit md5 value. Compare the md5 value obtained in step 4 with the sign value passed by the initiator in step 1, and pass.