1.验证用户信息接口

1.1接口说明

· 该接口为游戏服务器对SDK服务器发起的接口

· 该接口的功能主要为:游戏服务器通过token向SDK服务器验证用户信息

· token值会由SDK客户端告知给游戏客户端

· 成功返回1

· 同渠道UID绝对唯一，不同渠道UID可能重复，游戏服务器必须使用渠道ID + 渠道UID 方能确保游戏角色唯一

1.2 API地址

http://checkuser.quickapi.net/v2/checkUserInfo

备注:

a.此域名支持智能线路，国内/海外游戏均使用此域名

b.这个接口需放在服务器上请求，不能在前端请求

1.3 请求方式

GET/POST

1.4 参数列表

参数名称	重要性	说明
token	必须	游戏客户端从SDK客户端中获取的token值,原样传递无需解密,此值长度范围小于512,CP需预留足够长度
uid	必须	从客户端接口获取到的渠道原始uid,无需任何加工如拼接渠道ID等(注意：一定要传客户端返回的原始uid!!!)
product_code	选传	Quick后台查看游戏信息里可获取此值
channel_code	选传	传入此值将校验uid和token是否与channel_code一致,若游戏运营过程有发生玩家渠道间帐号转移,应确保此值正确 （该接口为客户端文档中的渠道类型接口）

备注:游戏从QuickSDK接口中获取的uid为渠道原始的UID,相同渠道UID唯一,不同渠道可能存在相同的UID(如Baidu有UID为1的用户,UC也有UID为1的用户).故游戏确定用户唯一身份时,需组合渠道ID和渠道UID两项参数.如: 渠道ID@渠道UID、渠道ID|渠道UID、渠道ID_渠道UID等组合方式

1.5 返回结果

返回结果为纯字符串

示例: 1

1为成功,其他值为失败

1.6 请求示例

http://checkuser.quickapi.net/v2/checkUserInfo?token=@178@83@173@158@157@88@108@86@118@98@117@107@105@106@108@99@104@120@108@103@112@123@125@106@96@101@104@110@104@115@105@101@169@187@175@156@163@183@152@164@101@155@134@217@160@158@157@87@115@103@102@105@101@99@105@99@99@110@105@92@85@154@157@152@165@163@158@163@121@151@90@112@90@100@102@87@157@151@219@196@217@215@134@165@121@163@225&uid=D2A864635A709FD302080B508FF98D49&product_code=64345624204336603757759703868145

2.充值同步接口

支付解密流程：（CallbackKey 用来解码通知的密文；Md5Key 用来验证签名）

游戏最终发放道具金额应以amount为准

1.收到回调参数（nt_data, sign, md5Sign）
2.计算md5(nt_data+sign+md5key)得到签名（md5key在quick后台获取）,与收到的md5Sign一致,则签名通过.
3.用callbackkey解密nt_data
4.解密成功后,游戏按照通知XML中的amount金额进行发放道具
计算签名是 nt_data和值 拼接 sign的值 再拼接 md5key 计算md5，算出的结果和 POST中的md5Sign 进行对比

2.1 接口说明

· 游戏将自身发放道具url填写至QuickSDK后台->参数配置->Callback_Url

· QuickSDK采用http post方式把需要回传参数以xml形式回传

· 游戏方Http获取参数的方式读取并解析回写自身数据库

· 所有参数值分别以第三章中的算法进行加/解密

· 同步通知中会告知游戏方.该笔充值来源的渠道(如360游戏、91助手)等

· 同步成功游戏方需要对该订单进行排重处理，检查是否处理过，处理过不再处理。处理成功回写大写的SUCCESS给QuickSDK（只能返回这7个纯字符串不能带其他字符）

· 发放道具接口的响应速度应在5秒以内，发放接口响应越慢，QuickSDK向此接口补发通知的频率也将变低

注：母包支付过程中，客户端点击后弹出的【支付成功】和【支付失败】选项仅用于发出客户端通知，服务器发送通知则是以是否使用此处创建的测试帐号且帐号余额足够为判断依据

2.2 请求时参数

QuickSDK服务器以POST请求游戏合作方时会使用如下参数：

参数名称	数据类型	说明
nt_data	string	通知数据解码后为xml格式 ,具体见2.1.1
sign	string	签名串,具体见第三章
md5Sign	string	计算方法为MD5(nt_data+sign+md5key),三个值直接拼接即可

参数都会被第四章中的加解密方式进行传递.游戏方需要对参数解密后方可获取到2.2.1中的明文XML

2.2.1 nt_data参数的XML格式

2.2.2 XML字段说明

参数名称	数据类型	重要性	说明
is_test	string	必有	是否为测试订单 1为测试 0为线上正式订单，游戏应根据情况确定上线后是否向测试订单发放道具。
channel	string	必有	渠道标示ID 注意:游戏可根据实情,确定发放道具时是否校验充值来源渠道是否与该角色注册渠道相符
channel_uid	string	必有	渠道用户唯一标示,该值从客户端GetUserId()中可获取
game_order	string	必有	游戏在调用QuickSDK发起支付时传递的游戏方订单,这里会原样传回
order_no	string	必有	QuickSDK唯一订单号
pay_time	string	必有	支付时间 2015-01-01 23:00:00
amount	string	必有	成交金额，单位元，游戏最终发放道具金额应以此为准
status	string	必有	充值状态:0成功, 1失败(为1时 应返回FAILED失败)
extras_params	string	必有	可为空,充值状态游戏客户端调用SDK发起支付时填写的透传参数.没有则为空
original_currency	string	可选	海外游戏返回此字段，玩家支付的原始币种
original_amount	string	可选	海外游戏返回此字段，玩家支付的原始币种金额

注意：

国内游戏 amount 为人民币元 ，游戏发货需时需验证下单金额与此金额，最终发货应以此金额为准
海外游戏 amount 为美元，此金额通常经过汇率换算，换算汇率以渠道汇率或QuickSDK配置汇率为准

3.MD5签名(同步接口)

3.1 签名说明

· 签名的字段名为md5Sign

· 签名是对接收到的密文原文进行计算的

3.2 算法描述

· 回调接口会接受到nt_data、sign、md5Sign 这3项参数

· 游戏采用md5(nt_data+sign+md5key)计算得到一个当前的md5SignLocal

· 游戏对比本地计算的md5SignLocal是否与接收到的md5Sign一致.一致则签名通过,不一致则签名验证失败

· md5Key由QuickSDK分配,可从QuickSDK后台获取

4.接口加解密(同步接口)

4.1 加密

4.1.1 加密算法描述

详情参见 附录1

4.2解密

4.2.1解密算法描述

详情参见 附录1

4.3示例

假设游戏收到QuickSDK回调参数如下:

nt_data=@116@119@168@161@165@88@170@153@167@170@161@163@166@113@87@99@94@102@83@85@153@166@154@164@155@157@166@152@114@90@140@135@126@101@104@86@89@171@168@149@163@155@153@160@167@162@154@111@82@164@160@87@115@118@115@168@162@173@165@160@164@166@170@146@165@157@163@167@154@159@153@114@113@164@157@167@171@149@156@151@110@114@154@168@147@172@156@168@171@114@104@109@100@161@170@146@172@157@163@168@119@116@151@156@150@165@166@153@164@114@109@106@104@110@109@100@151@160@152@163@165@153@164@111@113@155@159@148@166@166@149@160@152@173@157@152@115@105@107@101@112@104@106@110@95@153@153@150@162@166@156@161@150@169@161@149@115@116@158@148@165@157@143@163@171@156@153@166@115@104@106@103@108@105@107@105@104@111@109@100@155@153@164@154@150@163@170@149@154@170@117@111@167@170@148@153@171@151@162@163@115@104@106@105@106@100@102@104@96@108@98@103@101@105@107@103@105@100@108@101@102@105@109@107@108@107@99@112@104@167@166@152@154@169@151@162@167@114@113@162@145@175@144@169@157@165@156@115@105@100@105@103@98@104@109@96@105@106@80@101@106@114@104@102@111@105@104@112@103@164@150@171@143@170@154@162@153@118@115@150@164@163@173@159@169@118@104@97@104@104@108@99@154@165@163@169@163@171@118@112@171@168@150@166@165@169@111@101@112@103@170@169@152@168@173@164@115@116@156@171@172@170@145@167@152@168@149@166@150@164@171@114@179@101@178@145@171@104@174@113@99@157@175@169@169@149@171@144@165@153@169@148@165@171@110@112@104@165@153@167@168@152@159@153@118@112@100@165@155@175@158@164@163@166@170@148@164@153@171@164@150@159@156@113&sign=@106@154@147@150@154@155@153@150@151@157@106@103@153@101@110@107@150@104@103@150@104@155@152@154@109@109@158@101@109@111@156@99&md5Sign=c644c134144555807c228bd439f8264d

1.游戏收到3项数据后应校验签名是否正确:

计算md5(nt_data+sign+md5key)得到c644c134144555807c228bd439f8264d,与收到的md5Sign一致,则签名通过.

2.按照附录1解密nt_data得到如下xml:

0
8888
231845
123456789
12520160612114220441168433
2016-06-12 11:42:20
1.00
0
{1}_{2}

3.解密成功后,游戏按照通知XML中的amount金额进行发放道具

5.补单机制

游戏在接受到QuickSDK服务器通知后，应返回大写的SUCCESS，出于网络或某些原因，当QuickSDK不能正确收到发放道具接口响应时(返回不为SUCCESS)时，会以一定的机制再次补发请求。补发请求会在一段时间内持续进行.为了便于运营检查订单,游戏在返回失败时(非SUCCESS时),可以给出简明的错误提示.如:SignError、AmountError。需要注意的是，当游戏积累大量错误返回，系统将降低此游戏的补单频率，游戏开发者需正确开发发放道具接口。

6.附录1

6.1 加密算法伪码描述：

public static String encode(String src,String key) {
     try {
         byte[] data = src.getBytes(charset);
         byte[] keys = key.getBytes();
         StringBuilder sb = new StringBuilder();
         for (int i = 0; i < data.length; i++) { int n = (0xff & data[i]) + (0xff & keys[i % keys.length]); sb.append("@" + n); } return sb.toString(); }catch (UnsupportedEncodingException e){ e.printStackTrace(); } return src; }

6.2 解码算法伪码描述：

public static String decode(String src,String key) {
     if(src == null || src.length() == 0){
         return src;
     }
     Matcher m = pattern.matcher(src);
     List list = new ArrayList();
     while (m.find()) {
         try {
             String group = m.group();
             list.add(Integer.valueOf(group));
         } catch (Exception e) {
             e.printStackTrace();
             return src;
         }
     }
     if (list.size() > 0) {
         try {
             byte[] data = new byte[list.size()];
             byte[] keys = key.getBytes();
             for (int i = 0; i < data.length; i++) { data[i] = (byte) (list.get(i) - (0xff & keys[i % keys.length])); } return new String(data, charset); } catch (UnsupportedEncodingException e){ e.printStackTrace(); } return src; } else { return src; } }

6.3 key说明

加密解密所需的key，为接入游戏时，QuickSDK与游戏双方约定好的callbackkey。这个值通过QuickSDK控制台获取，【登录www.quicksdk.com】→选择【对应产品】→点击【参数配置】获取。

6.4 服务端资源下载说明

在官网的下载中心可获取服务端解密示例【QuickSDK For 服务器类库】，其中包含C#、C++、Java、PHP等示例Demo

7. FQA

Q:通知游戏显示“请求超时”要怎么处理?
A:
1.检查配置的游戏支付回调地址是否正确，前后是否有空格，能不能正常访问
2.回调地址如没有问题，就是游戏响应不及时，需要在5S内进行返回
3.如果游戏返回是及时的，则检査下游戏回调接口是否支持100-continue应答
由于QuicksDK采用了ibcur封装接口来对游戏回调地址进行htp清求，另外我们的回调业务数据较多且是采用了对称加密算法，于是出现了请求body超过了1024字节，此时则会触发一
个HTTP/1.1协议里的"Expect:100-continue"，具体流程如下:
a. 发送一个请求，包含一个"Expect:100-continue" 头域，询问Server是否愿意接收数据
b. 接收到Server返回的100-continue 应答以后，才把数据POST给Server
由于部分CP在实现回调服务Websener的时候采用了node或者C++或者Soin9等框架，它们默认是不支持100-contiue应答的，所以通常会表现为请求超时，CP自己模拟请求又能收
到数据，要解决此问题需要游戏回调接口支持下100-continue应答