经过两个多月的开发，一个微信第三方应用在我手上逐渐成形，下一阶段进入测试和上线阶段。刚开始的一无所知，认为其很是高大上，到了现在回头看看，却也没见得有太复杂的东西，但是爬过的那一个个坎现在都记忆非常深刻，开发微信第三方应用，其主要分为两个部分，授权部分和业务部分，业务部分的调用过程都需要授权部分所拿到的授权令牌，那我慢慢讲述。
一、授权部分，在授权的过程中需要对微信没十分钟推送的信息进行AES解密，得到ticket数据， 随着通过调用微信接口拿到componenttoken，这样反复取到数据有返回调用他的借口拿到新的授权数据，这么一个流程在最后一步的时候会是拼接出一个url，这个url会根据你传入的参数生成一个二维码供管理方进行扫码授权，当扫码通过后悔跳转到我们在url中配置的回调url，问题在于当时并不知道，这个url必须是生成在配置的域名下，并且附加参数会在扫码之后在回调的url后面拼接出来给我们，为此我请求多路大神，决定将回调的url写成接口，当扫码跳转之后我便通过在扫码跳转触发调用接口后在http请求头中拿到相关信息。
二、业务中，未保证各部分稳定性，需要细分成三个工程，callback处理部分，上架部分，还有补仓部分，callback主要是接收用户支付成功或者领取成功后微信给我们推送过来的相关通知，为了保证数据和微信方的一致性，方便以后额双方对账，为此通过相关订单查到的信息我们必须在我们自己的库中进行保存存档，后来公司财务反映导入自身的支付码给微信具有安全不可控性，这对上上市公司会有要求，为此我们在保存数据的基础上再加上了激活动作，只有激活后用户才能够正常使用商品。当然，在这一部分还要开发一套能兼容多个产品的兼容性代码上架产品其实可以通过main方法直接调用接口进行，其主要麻烦点在于json结构体太过复杂，难于拼接，并且在更新货架的时候需要带上所有产品参数，不然的话新上传的产品直接覆盖之前的产品，这一点我认为微信放需要对接口进行改进及其退货申请、发票申请一些简单的能够兼容多个产品的html5页面，其主要难点在于每个品牌令牌是不一样的并且在很短时间内会进行更新变化，而调用微信段接口都需要此令牌，难点在此。补仓部分，则是通过定时调度的方式，每隔一定时间就是轮询执行调用微信接口查询库存情况，如果不足则需要从我库中取出数据对微信端进行导入。
这样回头看看所做的部分其实并没有太多困难的地方，但是在开发的时候还是会遇到很多问题，毕竟菜鸟一枚，作为几乎全是接口调用的一个部分，我认为和接口提供方做到充分沟通是很有必要的，并要有一份详细的接口文档，快速发现问题，这样才能够加速开发进程。