教你快速高效接入SDK——服务器端支付回调的处理方式

转载自:http://blog.csdn.net/chenjie19891104/article/details/48321427
今天着重把之前渠道服务器端SDK的时候,遇到的一个蛋疼的问题给解决了。
 
按照之前我们搭建U8Server的思路,U8Server是可以完美支持多款游戏的。包括登录认证和支付回调。登录认证,没啥好说的。统一的接口即可,和客户端的协议对应上。支付回调呢?各个渠道的支付回调逻辑,对于每款游戏来说都是一样的,然后每个游戏填写的登录回调地址,也都一样。
 
U8Server采用J2EE成熟框架实现,各个游戏的各个渠道的参数,是配置在数据库中,通过后台管理工具来完成添加,修改,删掉等操作。
 

前我们的流程,相信大家还记得。客户端在调用支付接口之前,首先会来U8Server获取一个订单号。这个时候,U8Server会在订单数据表中记录一
条数据,然后将生成的订单号,返回给客户端。客户端将该订单号放在渠道SDK的扩展字段或者固定订单号字段中传到SDK服务器。SDK服务器支付完成,回
调到U8Server的时候,会将这个订单号原封不动的返回。
 
这个时候,在每个渠道的支付回调方法中,我们首先获取到渠道SDK返回的参数中的订单号。然后根据该订单号来查找数据库中对应的订单信息,进而获取到当前支付的用户信息,渠道信息,游戏信息等相关联的数据
 

种方式,对于多数渠道来说,是OK的。但是在接安智和ITools的时候,我们发现,这些渠道在支付回调的时候,把所有的数据都进行了加密处理,支付回调
方法中,拿到这个参数无法直接获取到订单号,需要先拿到该渠道对应的解密密钥来对该加密过的参数进行解密,然后才能取到订单号等信息。
 
这就和我们之前的方式,就有冲突了。
 
我们是先解析参数,然后通过订单号,获取到渠道数据,再从渠道数据中获取当前渠道的配置数据(就是上面的解密密钥)。
但是现在这两个渠道是要求,我们先解密,再获取订单号。但是,解密需要的密钥,我们根本拿不到。因为我们是通过订单号获取渠道数据的。
 
后来想了想,能否通过URL地址,就直接获取到渠道号。比如,之前UC渠道,我们的支付回调地址是这样的:
 
http://192.168.1.88:8080/uc/payCallback
 
那么,现在,我们在配置渠道支付回调地址的时候,加上渠道号(比如当前游戏对应UC的渠道号为10):
 
http://192.168.1.88:8080/uc/payCallback/10
 
然后,在解析该URL地址的时候,我们需要通过某种方式,做一个URL重写。把类似的URL,给重写成如下形式:
 
http://192.168.1.88:8080/uc/payCallback?u8ChannelID=10
 
这样,我们就可以在UC渠道的支付回调方法payCallback中,直接获取到u8ChannelID=10.然后,就可以直接获取到渠道数据,进而获取到对应的配置数据。
 
好在,这种方式是完全可行的。我们采用J2EE(SSH2框架)来实现的U8Server,只需要再集成一个Tuckey UrlRewriteFilter 即可完成这样的URL重写。
 
关于该插件的使用很简单,网站上说明很详细,就不多说了。这里仅仅注意两点:
 
1、在web.xml中配置UrlRewriteFilter的时候,将其配置在struts2的Filter之前,否则URL重写无效
 
2、在struts2的filter-mapping中加上dispatcher的申明:
 
    <dispatcher>REQUEST</dispatcher>
   <dispatcher>FORWARD</dispatcher>
 
然后,在urlrewrite.xml中配置我们需要的重写规则正则表达式即可:
 
<rule>
   <from>^/(.*)/payCallback/([0-9]+)</from>
   <to>/$1/payCallback?u8ChannelID=$2</to>
</rule>
 
现在访问这些地址:
 
   http://192.168.1.88:8080/uc/payCallback/10
   http://192.168.1.88:8080/downjoy/payCallback/11
   http://192.168.1.88:8080/anzhi/payCallback/39
 
都会变成如下形式:
 
   http://192.168.1.88:8080/uc/payCallback?u8ChannelID=10
   http://192.168.1.88:8080/downjoy/payCallback?u8ChannelID=11
   http://192.168.1.88:8080/anzhi/payCallback?u8ChannelID=39
 
这样,所有渠道的支付回调地址就统一了,全部为如下形式:
  
   http://{host}/{channel}/payCallback/{channelID}
 
在这里,顺便说一句。之前和很多童鞋的沟通交流中发现,%80以上的客户端的SDK接入同学,都只关注SDK客户端的接入,对服务器端的接入,一无所知,也不愿意着手去思考和研究。
 

然,可能服务器端不需要你去做,但是了解一下服务器端的接入原理,对SDK接入来说,可以培养起很好的大局观。SDK接入本身并不难,但是要做到高效,简
洁,易于扩展和维护还是需要花费些心思的。(之前朋友所在的游戏公司招聘专门负责SDK接入的技术总监,月薪30K,你扪心自问,能够胜任吗?)
 

希望这些从事SDK接入的同学能够早日明白这一点

上一篇:Bate敏捷冲刺每日报告--day3


下一篇:在Flex中推断是否在组件之外单击的技巧