业务场景
最近在做虚拟货币的"反向提现"(天朝不允许这么做, 只是擦边球啦), 所以起个高大上的名字"兑现". 我司创业公司, 财力单薄, 银联2000+的申请费, 千8的手续费自然让人望而却步. 于是乎苦思冥想下, 选择了微信做反向账户. 调研了n多文档, 结合自己的老司机经验, 选择了微信公众号的企业打款做给用户定向打款的业务功能组.
业务解析
那么好了从上面的业务分析图1中, 我们可以知道, 在已有技术资源渠道选定的情况下, 如何解决在移动app中实现公众号的企业打款api, 就成了解决业务问题的关键.
如业务分析图2中所示, 业务拆解分用户id转换, 打款api接入两步.
接口相关
<b>一. 微信公众号相关
1.获取access_token
文档地址: https://mp.weixin.qq.com/wiki/11/0e4b294685f817b95cbed85ba5e82b8f.html
请求方式: GET
请求地址:
https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=APPID&secret=APPSECRET
参数说明:
| 参数 | 必填 | 说明 |
|---|---|---|
| grant_type | 是 | 获取access_token填写client_credential |
| appid | 是 | 公众号的唯一id |
| secret | 是 | 公众号的密钥 |
返回示例:
200 OK
Connection: close
Date: Wed, 15 Feb 2017 02:15:24 GMT
Content-Type: application/json; encoding=utf-8
Content-Length: 154
{
"access_token": "zoma7kz-VdhDMDraUBrmW3ouVAa-64YAKE1Ce_LDAhMCftwcq1fjFE2X0WcjFUgWAcYQTTLYIKiK-I2OncrHMZ2_vpPvV9mwUvSvoVJTC2gKKUdAHASSC",
"expires_in": 7200
}
2.根据access_token得到open_id列表
文档地址: https://mp.weixin.qq.com/wiki/0/d0e07720fc711c02a3eab6ec33054804.html
请求方式: GET
请求地址:
https://api.weixin.qq.com/cgi-bin/user/get?access_token=ACCESS_TOKEN&next_openid=NEXT_OPENID
参数说明:
| 参数 | 必填 | 说明 |
|---|---|---|
| access_token | 是 | 调用接口的凭证 |
| next_openid | 是 | 第一个拉取的OPENID，不填默认从头开始拉取 |
返回示例:
有数据更新时:
200 OK
Connection: close
Date: Wed, 15 Feb 2017 07:06:27 GMT
Content-Type: application/json; encoding=utf-8
Content-Length: 272
{
"total": 6,
"count": 6,
"data": {
"openid": [
"olSBQxKIV7FCXx7WW0iQsXEoXE9k",
"olSBQxENCojqbp_c_11lOIGempI4",
"olSBQxILNooroKuHtNc9ioDMUsPQ",
"olSBQxISsjAh_kwrxTmjPZ_56NoQ",
"olSBQxPay4YhRs2kBCXrLMNDxxjs",
"olSBQxFQfuqw8yJcbyX3INjBxIGs"
]
},
"next_openid": "olSBQxFQfuqw8yJcbyX3INjBxIGs"
}
没有数据更新时:
200 OK
Connection: close
Date: Wed, 15 Feb 2017 07:13:02 GMT
Content-Type: application/json; encoding=utf-8
Content-Length: 38
{
"total": 6,
"count": 0,
"next_openid": ""
}
*特别说明返回示例中的next_openid的含义发生变化: 此时代表拉取用户列表的最后一个id! *
3.根据openid获取用户的基本信息
文档地址: https://mp.weixin.qq.com/wiki/14/bb5031008f1494a59c6f71fa0f319c66.html
请求方式: GET
请求地址:
https://api.weixin.qq.com/cgi-bin/user/info?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN
参数说明:
| 参数 | 必填 | 说明 |
|---|---|---|
| access_token | 是 | 调用接口的凭证 |
| openid | 是 | 普通用户的标识，对当前公众号唯一 |
| lang | 否 | 返回国家地区语言版本 |
返回示例:
200 OK
Connection: close
Date: Wed, 15 Feb 2017 07:20:28 GMT
Content-Type: application/json; encoding=utf-8
Content-Length: 421
{
"subscribe": 1,
"openid": "olSBQxKIV7FCXx7WW0iQsXEoXE9k",
"nickname": "BobRen࿐",
"sex": 1,
"language": "zh_CN",
"city": "朝阳",
"province": "北京",
"country": "中国",
"headimgurl": "http://wx.qlogo.cn/mmopen/8uptaMS0ibfVs1LyqliciaiajlKIcWYSMZd2B9JgK3g0qr63oyz18jUppZFa3naGS3r38NSAibLZvpicESZjDia6kIIv5f4mXW7s1ZI/0",
"subscribe_time": 1482460774,
"unionid": "IamUnionid",
"remark": "",
"groupid": 0,
"tagid_list": [ ]
}
以我为例, ok, 这里我们就拿到了我们朝思暮想的<unionid>, got it!
截止到此, 微信公众平台的部分搞定. 至于用户数据更新上, 建议用定时任务, 每天0:00或者几个静态时间点用next_openid拉取最新的数据.
二. 微信开放平台-移动app
通过"微信登陆授权"拿到unionid
文档地址:
https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419317851&token=4fab694b3d1260a639eeb0b5a98d81cf7919cacb&lang=zh_CN
具体api指向如下:
微信登陆-> 拉起微信-> 用户授权 -> code -> accesstoken && unionid
注意: 兑现功能的前置条件, 需要调起微信登陆!!! 这个设计有点奇葩, 但是如果用户信息未绑定微信账号, 只能如此, 暂时没有更好的处理方案.
存储相应的unionid到我司用户信息表中, 完成公众号 到 app的id信息关联, 齐活儿~
三. 业务实现方式总结
优点:
- 财务分离, 公司进账账户和出账账户完全分离, 一定程度上保证了财务安全.
- 较低的手续费, 0.6%的手续费, 感觉即使不盈利也像是在赚钱.
- 一定程度上降低了开发成本, 完全对着微信的api巴拉巴拉就行了.(不要和我说ping++, 提现功能解决不了)
- 现成的微信流水替代了财务系统的开发
- 提现的自动化api降低了客服的工作量
不足:
- 申请账号, 真尼玛麻烦, 各种资料劳神伤身
- 中间的穿域授权完全依托于微信登陆, 对于高质用户而言, 体验很一般
- 要提现, 还要关注微信公众账号, 累不累?(当然你也可以为, 解决刚性需求-- RMB, 顺便带点营销的小伎俩, 哈哈)
- 这么多, 这么多, 好久不用markdown, 好手残, 好手残
最后,
不得不说, 我的方案是有点反人类设计的方案, 其灵感也是在麻辣诱惑任职时, 为了解决公众号二次开发的商城退款问题而找的api, 并设计的方案, 在这个新平台上能实现并完善这个方案还是很欣慰的, 哈哈~
最后的最后, 我做码农的时间不是很长, 但总归是快乐的,不写业务代码也快半年了, 在项目管理和产品设计的scope也谈不上精进. 27的年龄, 会有些新的思考, 新的认知, 当然尽管发现自己渐乎是有些平庸的, 但总会想要挣扎下. 太久不写, 有些verbose了, 希望和各位交流技术, 共勉吧.
