TYPESDK手游聚合SDK客户端远程开关：渠道支付黑名单

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

渠道支付要做开关干嘛用呢？为什么要做这种东西呢？

这个教训来分享一下，我们的游戏上线公测了，59个渠道首发，其中包括了应用宝，UC，360等的大渠道，也包含有一些工会渠道和小渠道，上线后一切正常，但是到了下午就开始出现问题了，大渠道联系了我们的渠道商务说我们在做充值返利要立刻停止这种行为，限我们3小时内处理，要不然就下架我们的游戏。公司沟通了一圈后，一头雾水，因为运营和市场并没有做这种返利活动。后来询问大渠道后获得了一些相关的信息和截图，发现小渠道和一些二三级分包渠道在做4-6折不等的充值返利，我们下载了相关的apk发现多次打包和分销渠道号等。然后就是联系这些渠道关闭返利，给大渠道解释，多要一些时间等等，处理到了第二天，为什么会这么久呢？因为渠道商务人员要一家一家联系，联系对方后对方还要在去联系那些二三级分包渠道或者是合作渠道，这么一级一级的关系处理的很慢，随着时间过去渠道那里也下班了，最终导致游戏被大渠道下架了，而这些做返利的渠道也没量了。说到这里大家明白了这个需求的原因，那么总结一下是这样

1、上线渠道多，有些渠道为了业绩会做充值返利

2、大渠道的控制力很强，他们的多级渠道能力也很强，他们会比我们先发现这类问题

3、即使和渠道说了不要做充值返利，但是他们的沟通可能会出现误差，不能保证一定不会出现

4、这类事处理起来费事费力牵扯众多，短时间如果处理不好还有被大渠道下架的危险，这就得不偿失了

吃一堑长一智，为了解决这种混乱的情况，想出了这个渠道支付开关的功能，实现思路为在用户进行支付的时候从CDN的HTTP上下载一个配置文件，根据配置文件判断这个渠道是否能顺利支付

以下是接入游戏渠道的支付代码的实现代码

public String CallPayItem(final String _in_data)
{
TypeSDKLogger.i("CallPayItem:" + _in_data);
new Thread() {
@Override
public void run() {
String payMessage;
try {
payMessage = HttpUtil.http_get(TypeSDKBonjour_vivo
.Instance().platform
.GetData(AttName.SWITCHCONFIG_URL));
if (((payMessage.equals("") || payMessage.isEmpty()) && openPay)
|| TypeSDKTool.openPay(TypeSDKBonjour_vivo
.Instance().platform
.GetData(AttName.SDK_NAME), payMessage)) {
Handler mHandler = new Handler(Looper.getMainLooper());
mHandler.post(new Runnable(){
@Override
public void run() {
// TODO Auto-generated method stub
TypeSDKBonjour_vivo.Instance().PayItem(_in_context, _in_data);
}
});
} else {
TypeSDKNotify_vivo notify = new TypeSDKNotify_vivo();
TypeSDKData.PayInfoData payResult = new TypeSDKData.PayInfoData();
payResult.SetData(AttName.PAY_RESULT, "0");
notify.Pay(payResult.DataToString());
Handler dialogHandler = new Handler(Looper.getMainLooper());
dialogHandler.post(new Runnable(){
@Override
public void run() {
// TODO Auto-generated method stub
TypeSDKTool.showDialog("暂未开放充值！！！", _in_context);
}});
}
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
} }.start();
return "client pay function finished";
}